Fórum Root.cz
Hlavní témata => Vývoj => Téma založeno: dl 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).
-
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.
-
tady citace:
zdroj?
-
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? :-)
-
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).
-
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?
-
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
-
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.
-
to nepovedie k niecomu rozumnemu alebo funkcnemu
Bingo.
Vsázet se nebudu, věřím vám.
-
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.
-
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.
-
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.
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").
-
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í.
-
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.