[Java lista] switch

ern0 ern0 at linkbroker.hu
2008. Nov. 10., H, 08:35:59 CET


>> 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 :).

Ugy latom, hogy tkp. nincs koztunk nezetelteres. Vannak bizonyos 
szituaciok (pl. weboldal kiszolgalas), amikor specialis az eletciklus. A 
rovid eletciklusu objektumokrol frankon tudjuk, hogy mikor halnak (mint 
az iszlamista mosonok: koran - bocsanat). A hosszu eletciklusuakra 
celszeru GC-t kuldeni, gyorsabb is (lasd GC-thread, mint idle ido 
kihasznaloja), meg prgmozok altal vetett hibak ellen jobban ved. 
Mindazonaltal en nem butuska prgmozokkal szamolok.

> 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.

Azert el tudok kepzelni egy web kiszolgalo framework-ot, mondjuk olyan 
szigoritasokkal, hogy nem hasznalhat mindent a C++ kornyezetbol, ami van 
olyan kenyelmes, mint pl. a PHP. Majd megnezem, mit csinalt ez a Kornel 
gyerek, eleg ertelmesnek latszik.

>> 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?

Jaja.

> 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).

Na de ha valami obstack tipusu memoriakezelest hasznalsz, akkor az a 
legegyszerubb (foglalaskor csak pakolod szorosan egymas utan az 
objektumokat, aztan ha vege a bulinak, egy mozdulattal szorod ki oket). 
Nincs, GC, nincs egyenkenti free, 0.0000001 ms ido alatt purge ( 
memPtr[instance] = 0 ).

> munkatars, es berak egy igy keletkezett peldanyt valami maradando helyre
> (pl. session), es mar fel is robbant az alkalmazasod. Viszont a Sun

De hat azok a kivetelek. Senki nem tiltja meg, hogy ne a std, egyfele 
memoriakezelessel eljek.

Azert porgok ennyire a teman, mert pont kb. 2 hettel Kornel eloadasa 
elott kezdtem agyalni azon, hogy miert is nem C++ -ban irjuk a web 
appokat (na jo, erre azert volt egypar valaszom), pontosabben mi kene 
ehhez.

(OT: a masik csako eloadasa, illetve temaja se volt szar, a videokartya 
mint SMP, paran meg egy oraig faggattuk utana, incl. Kornel.)
-- 
ern0.scene.plus4.amiga.code.muzak
Haben Sie Fragen?


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