cetl jsem na foru, ze se da pouzivat java s vypnutym gc. mate stim nekdo zkusenost, je to mozne a bezpecne? dik.
tady citace:
quite a lot of what banks call low latency is done in Java. And not even Real Time Java - just normal Java with the GC turned off. The main trick here is to make sure you've exercised all of your code enough for the jit to have run before you switch a particular VM into prod ( so you have some startup looping that runs for a couple of minutes - and hot failover).
Když spojíš v Javě dva Stringy, tak se nejprve vytvoří StringBuilder, do kterého se oba nakopírují a potom se výsledné pole znaků klonuje pro nový řetězec, který se také instancuje. StringBuilder a jeho pole znaků se zahodí a bez GC zůstanou trčet v paměti.
O tom, ze by nekdo poustel Javu s vypnutym GC jsem moc neslysel (a prijde mi to trochu jako hloupost - freeze od gc je porad lepsi nez OutOfMemory, o tom, ze GC vetsinou Stop The World nezpusobi a vystaci si s vlastnim threadem nemluve).
Ale relativne casto se pouzivaji specialni datove struktury, ktere GC nepotrebuji - trebas ringbuffery.
ten quote je z http://stackoverflow.com/a/3600197
nasiel som toto http://architects.dzone.com/articles/why-can%E2%80%99t-i-turn-garbage
@dl, preco to chcete? :-)
Citace od: dl kdy 06. 04. 2014, 17:49:15
cetl jsem na foru, ze se da pouzivat java s vypnutym gc. mate stim nekdo zkusenost, je to mozne a bezpecne? dik.
tady citace:
quite a lot of what banks call low latency is done in Java. And not even Real Time Java - just normal Java with the GC turned off. The main trick here is to make sure you've exercised all of your code enough for the jit to have run before you switch a particular VM into prod ( so you have some startup looping that runs for a couple of minutes - and hot failover).
Jde to, ale asi to není úplně dobrý nápad. To už je lepší využívat nativní paměť (mimo haldu JVM).
Citace od: dl kdy 06. 04. 2014, 17:49:15
cetl jsem na foru, ze se da pouzivat java s vypnutym gc. mate stim nekdo zkusenost, je to mozne a bezpecne? dik.
tady citace:
quite a lot of what banks call low latency is done in Java. And not even Real Time Java - just normal Java with the GC turned off. The main trick here is to make sure you've exercised all of your code enough for the jit to have run before you switch a particular VM into prod ( so you have some startup looping that runs for a couple of minutes - and hot failover).
Proč? Proč bych si měl zvolit Javu, a pak ji prznit vypínáním GC? GC je naprostý základ na kterém Java stojí. Jestli nechcete GC, pište v C++. Pokud stojíte o to omezit vliv GC na běh aplikace v Javě, zvolte nějakou paralelní variantu GC (-XX:+UseConcMarkSweepGC nebo –XX:+UseG1GC) a napište aplikaci tak aby nevytvářela spoustu "garbage" a zapomeňte na to že GC existuje - pak to bude fungovat!
Pro lowlatency aplikace je vhodnější C++ (z výkonového hlediska nabízí mnohem více možností).
Javu takto sice využít jde, ale je to spíše pro její skalní příznivce než něco reálného.
jestli se nepletu tak: java nema destruktor. a tim ze existuje reference na objekt tak existuje. reference ukazuje na null, objekt se zrusi. jak by jste zarucil tuto funkcionalitu?
Citace od: dl kdy 06. 04. 2014, 17:49:15
se da pouzivat java s vypnutym gc.
To jsou nesmysly, nikdo to nešlo, nejde to a evidentně to nikdy nepůjde. Dá se alokovat paměť mimo GC, ale GC vypnout nelze z principu.
zrejme nepochopeni diskuze tazatelem. lze s vybranymi castmi zachazet tak, ze je bude GC ignorovat.
http://www.docjar.com/docs/api/sun/misc/Unsafe.html
Citace od: Kolemjdoucí kdy 07. 04. 2014, 09:30:25
GC vypnout nelze z principu.
Vsadis sa?
Myslim, ze to nepovedie k niecomu rozumnemu alebo funkcnemu, ale odstranenie casti programu by v opensource programe nemuselo byt dokonca ani velmi narocne.
Citace od: student kdy 07. 04. 2014, 14:52:00
to nepovedie k niecomu rozumnemu alebo funkcnemu
Bingo.
Vsázet se nebudu, věřím vám.
Citace od: smonty kdy 07. 04. 2014, 08:09:35
jestli se nepletu tak: java nema destruktor. a tim ze existuje reference na objekt tak existuje. reference ukazuje na null, objekt se zrusi. jak by jste zarucil tuto funkcionalitu?
Jen pro upřesnění: Obdobou destruktoru je v Javě metoda finalize(). GC ji volá, když na objekt už nevedou (poprvé) žádné reference. Docela vtipné na ní je, že má k dispozici referenci na objekt, takže ho může učinit opět dostupným a zabránit jeho vymazání. Každopádně nelze se spolehnout na to, kdy ji GC zavolá a kdy se objekt smaže. Takže programátor musí počítat s tím, že nic z toho se nestane "hned" poté, co na objekt už nebudou odkazovat žádné reference.
Citace od: smonty kdy 07. 04. 2014, 08:09:35
jestli se nepletu tak: java nema destruktor. a tim ze existuje reference na objekt tak existuje. reference ukazuje na null, objekt se zrusi. jak by jste zarucil tuto funkcionalitu?
Tak funguje počítání referencí. U GC v Javě by se objekt nezrušil hned. Místo destruktoru mají objekty finalizér, ale ten přináší jen problémy.
CitacePro lowlatency aplikace je vhodnější C++ (z výkonového hlediska nabízí mnohem více možností).
Javu takto sice využít jde, ale je to spíše pro její skalní příznivce než něco reálného.
Barclays vyuziva javu na 99% kodu ve svych high-frequency platformach. Tim high-frequnecy mam na mysli takove obchody, kdy zalezi na milisekundach a faktorem je i lokace serveru (server co nejbliz danemu "obcodnimu uzlu").
Citace od: Jakub Galgonek kdy 07. 04. 2014, 19:18:44
Citace od: smonty kdy 07. 04. 2014, 08:09:35
jestli se nepletu tak: java nema destruktor. a tim ze existuje reference na objekt tak existuje. reference ukazuje na null, objekt se zrusi. jak by jste zarucil tuto funkcionalitu?
Jen pro upřesnění: Obdobou destruktoru je v Javě metoda finalize(). GC ji volá, když na objekt už nevedou (poprvé) žádné reference. Docela vtipné na ní je, že má k dispozici referenci na objekt, takže ho může učinit opět dostupným a zabránit jeho vymazání. Každopádně nelze se spolehnout na to, kdy ji GC zavolá a kdy se objekt smaže. Takže programátor musí počítat s tím, že nic z toho se nestane "hned" poté, co na objekt už nebudou odkazovat žádné reference.
finalize má ještě další dost zásadní problémy:
- běží v jiném vlákně a program je v nedefinovaném stavu (může, ale nemusí běžet)
- používání zámků a synchronized snadno vede k deadlocku, protože vlákno držící zámek může být právě zablokované garbage collectorem
- hodně HODNĚ znesnadňuje garbage collectoru práci při nedostatku paměti; pokud máte finalize pro velké objekty, zahráváte si s OutOfMemoryException
- nikdy nevíte, jestli byl garbage collector vyvolán nedostatkem paměti; veškeré alokace ve finalize se pak rovnají ruské ruletě
- výjimky ve finalize se ignorují; pokud dokončení nějaké akce ve finalize (např. flush) může selhat, tak se o tom aplikace nedozví
A to obnovování reference ve
finalize bych doporučoval jen zkušeným masochistům.
TL;DR: v Javě nikdy nepoužívejte
finalize, pokud si nejste naprosto jisti tím, co děláte. Pokud je to jen trochu možné, tak
try/
finally je lepší řešení.
Citace od: Jakub Galgonek kdy 07. 04. 2014, 19:18:44
Jen pro upřesnění: Obdobou destruktoru je v Javě metoda finalize(). ... Každopádně nelze se spolehnout na to, kdy ji GC zavolá a kdy se objekt smaže.
Nelze se spolehnout dokonce ani na to, že ji vůbec zavolá. Garantováno je jen to, že na jednom objektu bude
finalize zavoláno nejvýše jednou.