Zkušenosti s jazykem D

[Pavel Tisnovsky]

Běžná aplikace (nějaké GUI kolem databáze + trochu business logiky) by s GC neměla mít problem. High performance kód by měl používat zásobník a vlastní alokátor.

Nemáte nějaký link na to, jak tohle dělat v Javě (jde-li to vůbec)? Zrovna včera jsem se snažil něco najít, ale neúspěšně.

Alokace na zasobniku - v Jave nejde, alespon ne na urovni bajtkodu (JIT si to ale tak muze prelozit a nekdy to dela, coz vsak moc neovlivnite z programu). Vlastni alokator pres ByteBuffer, ale budete si muset delat vsechno okolo prace s pameti sam a hlavne rozumet tomu, co se stane s objekty vytvarenymi mimo tento buffer, ale ktere na nej obsahuji reference. Muj soukromy nazor - vetsinou jde o zbytecnou preliminary optimization

[Reklama]

[Kozzi]

Zkoušel někdo z vás jazyk D? Jaké jsou dojmy? Já sem se na něj trošku koukal a teda nic moc. Straší tam GC. De sice vypnout, ale knihovna a některé language features pak moc dobře nefungujou. Plus, GC při zběru paměti freezne všechny vlákna (nevím jak sou na tom jiné GC, ale mám pocit že to de i bez freezu). Teda fakt netuším proč by člověk měl jít do D a ne třeba do javy ...

Ja vnem uz nejakou dobu pracuji a nemuzu si jej vynachvalit. Co se tyce GC, ano jsou urciute typy aplikaci kde to muze byt problem (tam idealne jak uz bylo psano je mozne si spravu pameti resit sam). Pro vetsinu aplikaci co jsem kdy psal je GC spis vyhoda. Jinak ohledne spravy pameti v D se ted hodne veci zlepsuje, teda minimalne je to jedna z hlavnich priorit. Jinak proc D misto  javy? Tak hlavne proto ze jazyk D je systemovy jazyk, to znamena umoznuje prave takove veci jako resit si vlastni alokaci pameti. A celkove umoznuje jazyk D opravdu skvele veci. Pokazde kdyz mam po nejake dobe psat neco v Jave tak uplne silim z toho co vsechno tam nejde tak snadno jako v D. Ale to je samozrejme o zvyku stejny problem mam i s C++.

Celkove je D velmi zajimavy jazyk a to zejmena diky svym vlastnostem. Pro me je hodne dulezita snadna podpora C knihoven.

[Radek Miček]

I pri pocitani referenci bude muset GC zastavit aktivni vlakna, rozdil je jen v tom, ze nemusi udelat STW pri oznacovani zivych/nezivych objektu. STW chovani lze omezit, napriklad tak, ze se vlakna zastavuji postupne, coz ale pro RT aplikaci je stejne spatne jako SWT

Pro RT aplikaci přeci stačí, když program poběží dostatečně často po dostatečně dlouhé doby.

To je tak jediná vada. Ale proto se používají slabé reference (__weak v ObjC, weak_ptr v STL, WinRT také něco má). Plně automatický GC má smysl jen když přesouvá přeživší objekty, čímž se zaručí deterministická alokace na haldě, jinak totiž přináší jen nevýhody.

Přesné počítání referencí má řadu dalších vad: Při alokaci mnoha krátce žijících objektů je výkon horší než u moderních vícegeneračních GC, těžko se efektivně implementuje pro konkurentní programy, nedeterministické uvolňování v konkurentních programech (nevíte, jaké vlákno spustí destruktor), lavinovité uvolňování. IMO počítání referencí má smysl pouze pro starší generace málo používaných objektů - viz třeba ulterior reference counting (a ani tam nepoužívají přesné počítání, protože to je příliš pomalé).

Jinak hlavní výhoda GC je modularita programů.

[Pavel Tisnovsky]

I pri pocitani referenci bude muset GC zastavit aktivni vlakna, rozdil je jen v tom, ze nemusi udelat STW pri oznacovani zivych/nezivych objektu. STW chovani lze omezit, napriklad tak, ze se vlakna zastavuji postupne, coz ale pro RT aplikaci je stejne spatne jako SWT

Pro RT aplikaci přeci stačí, když program poběží dostatečně často po dostatečně dlouhé doby.

Za predpokladu, ze budu mit jako programator moznost zarucit presnou dobu behu vlakna aplikace (+ maximalni povolenou dobu preruseni behu vlakna), tak rekneme ano, ale to v pripade GC (prakticky jakehokoli) nemam. Pod RT aplikaci si predstavme napriklad program, kteremu kontinualne prichazi po sbernici data a on je musi zarucene a za vsech okolnosti precist, aniz by pretekl buffer a data se ztratila. Obecne v beznem Linux/Windows prostredi to nejde zaridit a v pripade managovanych jazyku s GC taktez ne. "Resi" se to pouzitim mnohem silnejsiho zeleza nez by bylo zapotrebi a urcite davky rekneme viry, ze to proste bude fungovat

[zboj]

Pánové, já vás nechápu...proč se koukám na jazyk D? Sem zvědavý. Ano, vým, jde vytvořit gc bez freeznuti (reference counting). Ma však několik vad, třeba cyklicke datove struktury (jež se neuvolní). D má nějaký derivat mark and sweep (netuším jak maj přesně resenou fragmentaci). Takže, prosím, nenapadat me znalosti, pouze sem chtěl začít debatu. Pozoruji totiž že nabírá D na síle.

I pri pocitani referenci bude muset GC zastavit aktivni vlakna, rozdil je jen v tom, ze nemusi udelat STW pri oznacovani zivych/nezivych objektu. STW chovani lze omezit, napriklad tak, ze se vlakna zastavuji postupne, coz ale pro RT aplikaci je stejne spatne jako SWT

Při počítání referencí se jen atomicky sníží čítač referencí. Ostatních vláken se to nedotkne, pokud nesahají na stejný čítač.

[Reklama]

[Pavel Tisnovsky]

Pánové, já vás nechápu...proč se koukám na jazyk D? Sem zvědavý. Ano, vým, jde vytvořit gc bez freeznuti (reference counting). Ma však několik vad, třeba cyklicke datove struktury (jež se neuvolní). D má nějaký derivat mark and sweep (netuším jak maj přesně resenou fragmentaci). Takže, prosím, nenapadat me znalosti, pouze sem chtěl začít debatu. Pozoruji totiž že nabírá D na síle.

I pri pocitani referenci bude muset GC zastavit aktivni vlakna, rozdil je jen v tom, ze nemusi udelat STW pri oznacovani zivych/nezivych objektu. STW chovani lze omezit, napriklad tak, ze se vlakna zastavuji postupne, coz ale pro RT aplikaci je stejne spatne jako SWT

Při počítání referencí se jen atomicky sníží čítač referencí. Ostatních vláken se to nedotkne, pokud nesahají na stejný čítač.

Muze byt u jednoducheho objektu, ale uz u takoveho seznamu (kde si program udrzoval pouze referenci na HEAD/CAR) je to slozitejsi operace, a samotna atomicita muze znamenat nutnost locku nebo alespon CAS operaci. Navic se pojmem "reference counting" muze oznacovat nekolik ruznych technologii, muze to byt klidne spojeno s generacnimi GC, v nichz dochazi k presunum objektu na heapu (ale to jsme asi oba dva nemeli na mysli, navic to je spis problematika managovanych jazyku, v nichz neexistuje manipulace s primymi ukazateli).

[Radek Miček]

v pripade managovanych jazyku s GC taktez ne.

Proč to nejde zařídit v případě jazyků s GC? Čekal bych, že z parametrů programu (jako je rychlost alokace a rychlost generování odpadků) a parametrů GC (jako je rychlost zpracování) vypočtu, kolik času zbyde pro běh programu. Viz třeba článek "A Real-time Garbage Collector with Low Overhead and Consistent Utilization" od autorů Bacon, Cheng, Rajan, který v kapitole 4 obsahuje takovou analýzu pro kolektor Metronome.

[zboj]

Pánové, já vás nechápu...proč se koukám na jazyk D? Sem zvědavý. Ano, vým, jde vytvořit gc bez freeznuti (reference counting). Ma však několik vad, třeba cyklicke datove struktury (jež se neuvolní). D má nějaký derivat mark and sweep (netuším jak maj přesně resenou fragmentaci). Takže, prosím, nenapadat me znalosti, pouze sem chtěl začít debatu. Pozoruji totiž že nabírá D na síle.

I pri pocitani referenci bude muset GC zastavit aktivni vlakna, rozdil je jen v tom, ze nemusi udelat STW pri oznacovani zivych/nezivych objektu. STW chovani lze omezit, napriklad tak, ze se vlakna zastavuji postupne, coz ale pro RT aplikaci je stejne spatne jako SWT

Při počítání referencí se jen atomicky sníží čítač referencí. Ostatních vláken se to nedotkne, pokud nesahají na stejný čítač.

Muze byt u jednoducheho objektu, ale uz u takoveho seznamu (kde si program udrzoval pouze referenci na HEAD/CAR) je to slozitejsi operace, a samotna atomicita muze znamenat nutnost locku nebo alespon CAS operaci. Navic se pojmem "reference counting" muze oznacovat nekolik ruznych technologii, muze to byt klidne spojeno s generacnimi GC, v nichz dochazi k presunum objektu na heapu (ale to jsme asi oba dva nemeli na mysli, navic to je spis problematika managovanych jazyku, v nichz neexistuje manipulace s primymi ukazateli).

Jistě, u složitějších datových struktur může být zamykání komplikovanější, nicméně často je "konkurenční" chování efektivnější než kdyby se zastavila všechna vlákna. Navíc konkrétně v Cocoa se typicky provádí RC jen na hlavním vlákně (main loop), protože i callbacky na něm běží, a zbytek používá manuální správu paměti. Ale to už jsem odbočil.

[RAII]

Teď sem narazil na něco divného. Když sem se koukal na přetěžování operátorů v jazyce D, zjistil jsem že přetěžování operátorů new a delete je deprecated. Proboha proč, to si jako nepude napsat vlastní alokátor? Vysvětlení proč u toho nebylo. Taktéž sem někde viděl že scope proměnné budou též zrušeny. Hej, ty se s tím neserou, pro systémové programování je tendle jazyk tím pádem na nic (jo, OS s GC...). Sem trošku zklamaný, začal se mi líbit (x[] += y[] -> jak elegantní). Asi chtěj zabít RAII...

[Pavel Tisnovsky]

v pripade managovanych jazyku s GC taktez ne.

Proč to nejde zařídit v případě jazyků s GC? Čekal bych, že z parametrů programu (jako je rychlost alokace a rychlost generování odpadků) a parametrů GC (jako je rychlost zpracování) vypočtu, kolik času zbyde pro běh programu. Viz třeba článek "A Real-time Garbage Collector with Low Overhead and Consistent Utilization" od autorů Bacon, Cheng, Rajan, který v kapitole 4 obsahuje takovou analýzu pro kolektor Metronome.

Ano maji to tam analyzovane, ale ne pro vsechny pripady (predpokladam, ze nejaky dalsi clanek to objasni), napriklad velka pole a dalsi velke objekty. Dale mi tam schazi - ale mozna jen spatne ctu - analyza, co se stane pri velke fragmentaci heapu a naslednem pokusu o alokaci objektu. Btw uz samotny dukaz, ze treba nedojde pamet, je silene slozity /* mam volne tema na doktorskou praci! */, ten problem byl v clanku schvalne zjednodusen, ale to asi pro RT aplikace dostacuje, uznavam.

OT: Ono se vubec ukazuje, ze predpoklady, na kterych jsou postaveny generacni GC, nejsou vzdy splneny, hlavne to neplati u optimalizovanych aplikaci - tam generacni GC mnohdy nadelaji vic skody nez uzitku.

[Radek Miček]

Ano maji to tam analyzovane, ale ne pro vsechny pripady (predpokladam, ze nejaky dalsi clanek to objasni), napriklad velka pole a dalsi velke objekty.  Dale mi tam schazi - ale mozna jen spatne ctu - analyza, co se stane pri velke fragmentaci heapu a naslednem pokusu o alokaci objektu.

Velká pole reprezentují jako menší dvouúrovňová pole (viz 3.5). Velké fragmentaci předchází alokační strategií (viz 3.2) a defragmentací (viz 3.3).

[andy]

Niekde som videl prednasku o presnom GC. Robi to dost rozdiel pri programoch s gigovymi heapmi. Uz to tam maju? Inak ako jazyk sice fajn, ale zhanat/pisat bindingy na vsetko ma trosku odradza. To uz radsej to c++, zase az take hnusne to nie je.

[Pavel Tisnovsky]

Ano maji to tam analyzovane, ale ne pro vsechny pripady (predpokladam, ze nejaky dalsi clanek to objasni), napriklad velka pole a dalsi velke objekty.  Dale mi tam schazi - ale mozna jen spatne ctu - analyza, co se stane pri velke fragmentaci heapu a naslednem pokusu o alokaci objektu.

Velká pole reprezentují jako menší dvouúrovňová pole (viz 3.5). Velké fragmentaci předchází alokační strategií (viz 3.2) a defragmentací (viz 3.3).

S temi poli to budou mit jeste v praxi slozite. Vim to, protoze s temito velkymi objekty (humongous object) maji problemy vlastne vsechny soucasne GC, jak ty generacni, tak i ty zalozene na heapu rozdelenem na mnoho stejne velkych oblasti (Shenandoah GC). Z toho vyplyva i pouceni - pozor v Jave/C#/foobar na dlouhe vektory a matice, kdyz uz je skutecne potrbujete, tak nekdy pomuze ByteBuffer ;-)

[randolf]

Běžná aplikace (nějaké GUI kolem databáze + trochu business logiky) by s GC neměla mít problem. High performance kód by měl používat zásobník a vlastní alokátor.

Nemáte nějaký link na to, jak tohle dělat v Javě (jde-li to vůbec)? Zrovna včera jsem se snažil něco najít, ale neúspěšně.

Real Time Java Specification
http://www.rtsj.org/docs/docs.html

Memory management. There are two new types of memory areas that help prevent unpredictable delays commonly caused by traditional garbage collectors in real-time applications: immortal memory and scoped memory. Immortal memory holds objects without destroying them, except when the program ends. This means that objects created in immortal memory must be carefully allocated and managed, as with C programs. Scoped memory is used only while a process works within a particular section, or scope, of the program (such as in a method). Objects are automatically destroyed when the process leaves the scope. Neither immortal nor scoped memories are garbage collected, so using them avoids problems of GC interference. The Java RTS also provides limited support for providing memory allocation budgets for threads using memory areas. Maximum memory area consumption and maximum allocation rates for individual real-time threads may be specified when the thread is created.

[Kolemjdoucí]

GC při zběru paměti freezne všechny vlákna (nevím jak sou na tom jiné GC, ale mám pocit že to de i bez freezu).

Až se váš pocit změní v jistotu tím že najdete implementaci GC která nebude potřebovat "stop the world" neboli zastavení všech vláken tak nám prosím dejte vědět.

Concurrent Garbage Collector

To je sice pěkný název, ale já jsem se ptal na konkrétní implementaci. Ve všech implementacích které měly v názvu slovo concurrent jsem bohužel zatím vždycky našel i fázi která "stop the world" potřebovala, i když obvykle na kratší dobu než implementace které v názvu slovo concurrent neměly.