W dniu środa, 28 listopada 2012 14:59:25 UTC-5 użytkownik slawek napisał:
> Użytkownik "kenobi" napisał w wiadomości grup
> dyskusyjnych:1ffc9e93-a4f8-4a4e-b43e-7e7a64531534@go
oglegroups.com...
> >1) rozmaite 'nie zwalnianie' obiektow,
> Jest ok, podobnie jak w C++/CLR wskaźniki^

Pierwsze gc powstawalo w 80tych, przy chyba 16K pamieci. Jest ok.

> >2) rozmaite 'przekazywanie' (i wrappowanie) obiektow itp
> Sorry, ale to jest ok nawet w zwykłym C - programowanie z użyciem
> interfejsów (tj. wskaźników do struktur, które to struktury są nieobjaśnione
> w .h)

Trzeba faktycznie sprobowac zaimplementowac gc, zeby wiedziec tak
naprwade z czym to sie je. Wtedy latwiej jest zrozumiec co oznacza
"find nearest gc root" czy powod istnienia generacji w Javie
jak i doymslnie braku przeczesywania klas i ogolnie permGena.

> >tj czy jawie mozna zaufac ze nmie przejmujac sie
> Można. Ale IMHO te zwalnianie następuje jednak kiedyś, gdzieś, jakoś. I
> wtedy zapewne będzie obciążało CPU.

Ten, no, jawie mozna ufac, snu tez.

Powstalo sporo prac na temat benchmarkow Javy m.in. z tego powodu. Wiele
metod benchmarku nie uwzglednia gc, co jest takim machaniem rekami.
Oprocz gc dochodza generacje obiektow, JIT, miedzywatkowe optymalizacje
i wiele innych, ale nawet powazne publikacje nt. benchmarkow Javy
ograniczaja sie do uwglednienia gc, bo tak naprawde nikt tego nie ogarnia.

--
Edek