[Java lista] switch

Marai Laszlo lists at atleta.hu
2008. Nov. 10., H, 02:05:37 CET


On Sun, 09 Nov 2008 23:08:15 +0100
ern0 <ern0 at linkbroker.hu> wrote:

  Hali!

> 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

Azt irtam, hogy nem mindig tudod mikortol nincs rajuk szukseg. Hogy mikor
keletkeznek az eleg trivialis, nem is ez a kozponti kerdes a memoria
managementben :). Az alatt, hogy nem tudod, hogy mikortol nincs rajuk
szukseg, pedig azt ertettem, hogy nem tudod elore egyszeruen meghatarozni
a program egy adott helyet, ahol el tudod vegezni a felszabaditast.
Persze a program logika es/vagy az objektum modell megeroszakolasaval
megoldhato a dolog, de a cel pont az lenne, hogy erre ne legyen szukseg.

> vagy s.k., vagy megrendelte egy factory-tol, es amikor o meg fog halni,
> akkor vagy meghagyja hagyatekkent, vagy elpucolja az altala
> letrehozottakat.

Aha. Es ha tobben hivatkoznak ra, akkor mi van? Es honnan tudod, hogy kik
hivatkoznak? C/C++-ban ezt szepen le kell dokumentalni, illetve a
kulonfele metodus szignaturakbol kovetkezik. Pl. const* -t ugye nem lehet
torolni. Egeszen az elso const_cast-ig. Namost a rovideletu
objektumoknal, ahogy irtam, eleg egyertelmu, hogy mi az eletciklus, de ez
c++-ben is megoldhato auto_ptr-rel, vagyis a stack altal vezerelve. Gond
akkor van - es erre utaltam az elozoekben - ha letrehozol egy objektumot,
amivel mindenfele muveleteket vegzel, es mondjuk tenyleg el tudod dobni a
blokk vegen, aztan valtoztatsz egy kicsit a kodon, beraksz megegy metodus
hivast aminek parameterkent atadod ezt az addig ismert eletciklusu
objektumot, de az a metodus megtart ra egy referenciat.

Sot, hat igazabol minden metodus hivasra fogyelned kell onnantol kezdve,
hogy az vajon mit csinal a parameterkent kapott referenciaval. Mar be is
lehet vezetni a const*-hoz hasonlo jelolest. Persze figyelni hiaba
figyelsz, mert az ember hibazik, es a legkonnyeb ugy hibazni, hogy utolag
valtoztatsz valamit a kodon (rossz esetben mas kodjan).

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

Szerintem eletciklus. Marpedig ez a lenyege. Ahogy Verhas Peter irta ez
egy altalanos megoldas egy minden programban felmerulo problemara.
Enelkul minden esetben lehetne rajta kulon gondolkodni, tokolni, meg
aztan hibat keresni. Mindenkinek adott mennyisegu agyi kapacitasa meg
ideje van, en inkabb a lenyegi problema megoldasara forditom :).

> folytatasa annak az utnak, amit a prgmozas gyakorlatanak fejlodese

Igy van, dolgozzon a gep. Az ehavi newtech meetupon (jar valaki?) egy
srac arrol tartott egy igen gyengecske eloadast, hogy hogy lehet C++-ban
szupergyors webszolgaltatast irni. (A ppl.hu-t igy csinaltak, allitolag
2M oldalt szolgaltak ki vele naponta 5% terheles mellett egy Athlon
700-as geppel.) Na neki volt egy olyan tartalmu megjegyzese, hogy hat
ahhoz, C++-ban programozzon az ember, ahhoz okosabbnak kell lenni, mint
mondjuk PHP-hez. Csakhat ugye nem mindegy, hogy mire hasznalod el az
idod.

> Es ha mar van multithreading, miert ne lehetne mindig egy GC thread,
> aki idle idoben vegzi el a cleanup-funkciokat? Sok objektum (peldany) 

Van. Vagy ez meg a fejlodestortenetrol szolo reszhez tartozott?

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

Persze: http://www.hpl.hp.com/personal/Hans_Boehm/gc/

> Pl. ha egy weboldalat kellene kigeneralni C/C++-szal, akkor az lenne a 
> megoldasom, hogy

Igen, mondjuk a webes feluletu alkalmazasok a request/response es a
(viszonylagos) allapotmentesseg miatt relativ egyszeruek memoriakezelesi
szempontbol. Foleg, ha az allapot mindig a DB-ben tarolodik. Bejon egy
keres, legyartasz egy rakat objektumot, es a vegen mindent eldobalsz.
Viszont ugyanemiatt szerintem a GC is eleg jol elbanik veluk (csupa
rovideletu objektum, amiket eleg gyorsan ki lehet pucolni).

> - az oldal generalo prgmnak jo nagy, fix meretu memoriat foglalnek 
> elore, ami ugymond kitolti a rendelkezesre allo memoriat (minusz oprsz, 
> sql server stb.),

A JVM pont ezt csinalja :). Command line opciokkal lehet
hangolni a minimum/maximum memoria meretet pl.

> - csak a legvegen, amikor az oldal generalas elkeszult, illetve akkor 
> sem szabaditanam fel, csak lehet elorol csipegetni.

Hat igen, azt nem tudod megtenni, hogy egy pointer allitassal eldobsz
minden objektumot. De ez ugye amugy is veszelyes, mert egyszer jon egy
munkatars, es berak egy igy keletkezett peldanyt valami maradando helyre
(pl. session), es mar fel is robbant az alkalmazasod. Viszont a Sun
hotspot altal alkalmazott tobb generacios (generational) GC pont erre van
kihegyezve. A rovid eletu objektumok - es azt irjak
(http://java.sun.com/docs/hotspot/gc5.0/gc_tuning_5.html) hogy a legtobb
alkalmazasnal ezek vannak tobbsegben - gyorsan elpusztithatok. Csak az
elerheto objektumokat kell bejarni a legfiatalabb generacioban, es a tobbi
mehet a kukaba. Marpedig ha ugy mukodik egy servlet, ahogy az elobb
leirtad, akkor nem hagy maga utan elerheto objektumot, azoknak meg 0 ido
a GC-je.

> Nu ja, Java-ban egy ilyesmit nehez megcsinalni, viszont C/C++-ban meg a 

A parhuzamos requestek szamat siman tudod korlatonzi, a rendszer alul meg
ilyesmit csinal. Erdekes lenne egy osszehasonlitas egy ilyen egyszeru
oldalgeneralos peldanal. Szerintem nem lenne nagy kulonbseg. Az, hogy a
valosagban van, az annak lehet a kovetkezmenye, hogy a GCnek is
koszonhetoen azert ennel jellemzoen bonyolultabb rendszereket epitunk
mindenfele cache-ekkel, template enginekkel, sessionbe pakolt
objektumokkal (amikkel a te modelledben kulon kene foglalkozni), stb.

> GC (mint memoriakezelesi strategia) - bar biztos van hozza - nem lehet 
> egyszeru.

libgc6 :), a mukodesi elve ugyanugy mark&sweep mint a javanal (ill. hat
valoszinuleg a java megoldas szarmazik innen).

  atleta


További információk a(z) Javalist levelezőlistáról