[Java lista] switch

[ern0]

atleta:
 > De hat a lenyeg az, hogy a legtobb esetben nem tudod pontosan, hogy
 > mikortol nincs rajuk szukseg, vagy legalabbis ezt nagyon munkas
 > kitalalni. Teljesen altalanos esetben egy GC-t kell hozza irni ;).

Azert azok az objektumok nem az erdoben nonek, es nem a tudobaj viszi el 
oket, hogy ne tudjam, mikor keletkeztek es meddig kellenek. En igenis 
tudom, meddig kellenek. Valami masik objektum letrehozta oket vagy s.k., 
vagy megrendelte egy factory-tol, es amikor o meg fog halni, akkor vagy 
meghagyja hagyatekkent, vagy elpucolja az altala letrehozottakat.

Nem szeretem, ha valaki azert kedveli a GC-t, mert nem kell torodni a 
birtoklassal vagy hogy hivjak ezt.

Furanak hathat, hogy ennek ellenere szerintem a GC az egyenes folytatasa 
annak az utnak, amit a prgmozas gyakorlatanak fejlodese bejart az elmult 
evekben, ertem ezalatt, hogy kb. soros -> proceduralis -> oop (a pontos 
elnevezeseket nem ismerem). Azt talan nem kell ecsetelnem, hogy a 
multithreading az egy szalu oop-hoz kepest hatalmas lehetosegeket rejt. 
Fura, hogy egy "technologia" okozza ezt, de ha jobban belegondolunk, a 
stackon letrehozott lokalis valtozok is hasonlo "technologiai" megoldas 
volt (persze q. regen).

Es ha mar van multithreading, miert ne lehetne mindig egy GC thread, aki 
idle idoben vegzi el a cleanup-funkciokat? Sok objektum (peldany) 
hasznalata eseten nagyon kivilaglik, de keves objektum eseten is 
belathato, hogy az olyan _improduktuv_ feladatokat, mint amelyek a 
cleanup-ban vannak (incl. mem free), celszerubb nem azonnal elvegezni, 
hanem akkorra hagyni, amikor nincs mas melo.

Gondoljatok a mosogatasra! Ha azonnal elmosogatsz, lekesed a krimi 
elejet, viszont lesz eleg idod, amikor a reklam megy. Esetleg megkered a 
masik thread-et :-)

Peter Verhas wrote:
> Megtisztelve érzem magam, hogy ern0 barátomnak új dolgot mondhatok:
> 
> C-ben (meg C++-ban) az objektumaidat felszabadítod, Java-ban pedig
> nem? Nos a következő a helyzet:
> 
> C-ben meghívod a 'free' függvényt, és ezzel _jelzed_ a memóriakezelő
> számára, hogy az a memória neked nem kell. Majd ő felszabadítja,
> újrafelhasználja ha és ahogy és amikor akarja. Nyilvántartod magadnak,
> hogy mikor és meddig kell neked a memória terület, újra és újra
> leprogramozod a nyilvántartást, és amikor senkinek nem kell, akkor azt
> mondod, hogy 'free'.

Azert tul sokat nem okoskodik rajta, mindossze arrol van szo, hogy a 
malloc/free (meg az obstack meg meg ami van) egy layer az oprendszer es 
a prgmod kozott.

> A C-beli módszer sokkal hatékonyabb kódot eredményez, ha nincs benne
> hiba és ha jól programoztad le. Ha nem programoztad le jól, akkor
> elszáll, és akkor lassabb is lehet a memória kezelés, mint a JVM
> memória kezelése és a GC.

Pontosabban mem leak lesz, es az "nem jo".

> tanultuk (én pl. 1984-ben), hogy a 'free' az nem szabadít fel, csak
> megjelöli a memória darabot, mint felszabadíthatót.

Pontosabban, azt olvastam, hogy a C standard library ugy foglal memoriat 
(marmint a malloc/free-rol beszelunk, mivel a new/delete ezt hasznalja), 
hogy
1. minden memoriafoglalasi blokk (amit malloc()-kal kersz) meretet 
felkerekiti 2 hatvanyara, de legalabb 16 byte-ra (vagy valami e korulire);
2. minden kulonbozo meretu blokknak kulon pool-t tart fenn (egyet a 
16-osoknak, egyet a 32-eseknek), egeszen a page size-ig (ami az 
oprendszer memoriafoglalasi egysege);
3. a felkerekites utan azonos meretu blokkokat a megfelelo pool-bol 
szolgalja ki, eloszor meglevo page-ben keres ures helyeket, ha nincs, uj 
page-t foglal;
4. a kulonbozo meretu blokkok kulon pool-ba kerulnek (azaz ha a prg egy 
32->32 es egy 33->64 byte-os foglalassal indit, az 2 page lesz);
5. a page-nal nagyobb meretu blokkoknak kulon page-eket foglal, az 
utolso page-be mas nem kerul;
6. na meg persze kell hely a tablazatoknak.

Free eseten egyertelmu: ha egy page-ben minden blokk free-re kerult, 
akkor azt visszaadja.

More info:
http://www.aquaphoenix.com/ref/gnu_c_library/libc_18.html#SEC18

Fentiek fenyeben ertheto, hogy miert nem okoz feltetlenul segfault-ot 
egy kisse tulszaladt cimzes, vagy egy mar felszabaditott objektum 
hasznalata.

Bevallom, en csak nemreg tudtam meg ezt, viszont nagyon tetszik; nem 
vagyok egy elmeleti matematikus, de azt hiszem, altalanos celra ez ha a 
memoriafoglalas szempontjabol nem, de ha az adminisztracio koltsegeit is 
belevesszuk, valoszinuleg optimalis megoldas.

Termeszetesen ha egy prgm eseteben sulyponti kerdes a memoriahasznalat 
(ugye, ami a fenti modellt szivatja, az a 2 hatvanyanal eggyel nagyobb, 
kulonbozo meretu kicsi, es a page size-nal eggyel nagyobb blokkok 
esete), akkor erdemes megfontolni az obstack-ok hasznalatat (stack 
tipusu memoriafoglalasi terkep, mindig csak az utoljara lefoglalt 
szabadithato fel, persze egyszerre hasznalhato tobb obstack is)

http://www.aquaphoenix.com/ref/gnu_c_library/libc_33.html#SEC33

vagy kiokumlalhato sajat memoriafoglalasi strategia, netantan GC 
hasznalata (feltetelezem, van ilyen C++-hoz is).

Pl. ha egy weboldalat kellene kigeneralni C/C++-szal, akkor az lenne a 
megoldasom, hogy
- meghataroznam, hogy egyszerre parhuzamosan mennyi oldalat lehet 
lekerni a rendszerbol,
- biztositanam, hogy ne is lehessen tobbet lekerni,
- az oldal generalo prgmnak jo nagy, fix meretu memoriat foglalnek 
elore, ami ugymond kitolti a rendelkezesre allo memoriat (minusz oprsz, 
sql server stb.),
- a malloc/new primitiven ebbol csipegetne, egyre csak fogyasztana,
- es persze nincs free/delete,
- csak a legvegen, amikor az oldal generalas elkeszult, illetve akkor 
sem szabaditanam fel, csak lehet elorol csipegetni.

Ha keves a fix meret, akkor csokkentenem az egyszerre kiszolgalhato 
oldalak szamat, vagy vennek memoriat.

Lehet, hogy a konkret peldara van jobb, mar bevalt megoldas, csak azt 
akartam szemleltetni, hogy lehet olyan eset, amikor a memoriafoglalas 
sajat erobol megoldasa segithet.

Nu ja, Java-ban egy ilyesmit nehez megcsinalni, viszont C/C++-ban meg a 
GC (mint memoriakezelesi strategia) - bar biztos van hozza - nem lehet 
egyszeru.
-- 
ern0.scene.plus4.amiga.code.muzak
Haben Sie Fragen?