Názory k článku
V8: JavaScript uvnitř Google Chrome

kdo raději programuje v C než v JavaScriptu, ať zvedne ruku...

ja se teda hlasim...

U některých je to ale poprvé, co byly použity u interpretu JavaScriptu v prohlížeči, a často nejsou implementovány ani u interpretů jiných dynamických skriptovacích jazyků.

uzitecnost tech vlastnosti je totiz casto velice sporna a muze vest k celkovemu zpomaleni aplikace.

Autor možná narážel na Python. Tam je reference counting + detekce cyklů. Problémem není ani tak rychlost, ale spíš existence globálního zámku (GIL), protože synchronizovat každou (de/in)krementaci by bylo ještě horší.

Jinak super článek.

Autor možná narážel na Python. Tam je reference counting + detekce cyklů.

Nenarážel, toto je pro mě novinka. Python znám jen zběžně.

pythoni gc je taky vicegeneracni.

lze vlastnosti (konfiguraci) gc v prohlizecich nejak menit?

Nevím o žádném prohlížeči, kde by to šlo.

ja se teda hlasim...

Věděl jsem, že se někdo najde :-)

uzitecnost tech vlastnosti je totiz casto velice sporna a muze vest k celkovemu zpomaleni aplikace.

V tom případě je otázka, proč své garbage collectory podobným směrem rozvíjí třeba Sun ve své JVM nebo Microsoft v .NET. Kdyby byly "nadupané" garbage collectory méně výkoné, než ty jednoduché, tak by je přeci vývojáři neimplementovali.

Mám dojem, že tímto neobjektivním (a nepravdivým) příspěvkem jste se právě vyřadil z věcné diskuze.

mozna proto, ze napsat slusny garbage collector je docela veda... napriklad incrementalni GC umoznuje programu bezet plynulej, ale za cenu ze celkovy cas straveny v GC se zvysi, atd.

Pravil uživatel Boehmova konzervativního GC :-)

A pokud vím, všechny zmíněné techniky jsou dneska v podstatě mainstream (i když psát inkrementální algoritmus bych nechtěl, to přebarvování jsem zatím moc nepochopil :-) ) a o tom, že by jejich užitečnost byla sporná, slyším prvně. Nebyly by nějaké odkazy?

Pravil uživatel Boehmova konzervativního GC :-)

zkusil jsem spoustu 3rd party collectoru a boehmuv GC je bohuzel jediny (OSS) poradne pouzitelny (portabilni, multithreadovy,...)

Nebyly by nějaké odkazy?

ne... vsechno jsem si to bohuzel musel overit sam... :-/

Přijde mi to divný. Vždyť to v podstatě všechno vymysleli Lispaři :-)

LISPari vymysleli spoustu chytrych veci. o tom zadna... (mimochodem i ten typ kompilace, ktery je pouzity ve V8 jsou uz videl v nejakem lispovem prekladaci)

velky problem soucasnych GC je, ze nejvetsi vyvoj se deje kolem JVM a ostatni jazyky tak nejak sbiraji jenom drobky...

Já nevím, a proč je to problém? Chlapci od JVM se poslední dobou snaží udělat z toho svého bazmeku univerzální virtuální mašinu a podle toho, co se děje kolem MLVM (Da Vinci Machine), to vypadá nadějně. Garbage collectorů mají hromadu už teď, a jsou docela konfigurovatelné, do Javy 7 by měl přibýt další (což mi připomíná, že si musím konečně najít čas na ten článek o G1).

Super clanek, diky za nej...

Děuji za pochvaly :-)

Nevím jestli je úplně stejná, ale podobná určitě (alespoň podle toho mála, co o vnitřku .NETu vím).

Možná by byl zajímavý článek, který by porovnával garbage collectory v různých reálně používaných jazycích/prostředích.

GC u V8 je tu popsan jen zhruba, ale ano, je to dost podobne .NETu. Ten ma GC "compacting", tj. udrzuje souvislou oblast obsazene pameti - alokace objektu tak znamena jen zvyseni hranice tehle oblasti, garbage collection pak "sesype" objekty za sebe.
Take pouziva vice generaci (3?), kdy se starsi generace neprohledavaji - a ted si nejsem jisty, jestli si neudrzuje i seznam ukazatelu z nich jako dalsi koreny pro GC.
Videl jsem o tom moc pekny clanek - pokud by mel nekdo extra zajem, muzu zkusit vyhrabat link...

GC u V8 je tu popsan jen zhruba, ale ano, je to dost podobne .NETu. Ten ma GC "compacting", tj. udrzuje souvislou oblast obsazene pameti

Garbage collector V8 je také částečně "compacting", detaily se dají nalézt ve videu odkázaném v článku. Do článku jsem to opoměl zmínit.

Ja by měl zájem převeliký.

Kopírovací GC je compacting tak nějak z definice :-)

Kopírovací GC udržuje heap kompaktní, to nepopřete. A to jsem měl na mysli. Co je mimochodem compacting GC? Neexistuje jenom mark and compact.

Pokud si to dobře pamatuju z Google DevDay, GC ve V8 je pro mladší generaci kopírovací, pro starší mark and sweep, což je taková klasická kombinace.

Teď na to ještě koukám, a je to ještě trochu zajímavější (slajd č. 18).

Ano, garbage collector V8 je trochu komplikovanější než je popsáno v článku. Nechtěl jsem to z důvodů srozumitelnosti a omezeného prostoru až tak rozepisovat, tak jsem pouze zmínil, že popisuji jen jeden z jeho možných průchodů. Ostatně, Google to tak v některých svých materiálech dělá také a fakt, že popisuje jen něco, ani nezmiňuje.

Není někde ještě něco k té reprezentaci hodnot? Nebo aspoň jméno souboru zdrojáku v8, kde se to řeší. Dík.

Výklad o reprezentaci hodnot jsem se snažil vzít jen stručně, protože tohoto tématu jsme se už dotkli jak u SquirrelFish, tak u SpiderMonkey a V8 se od nich zas tak neliší. Pokud máte nějaké konkrétní otázky, můžu je zkusit zodpovědět nebo vás navést, kde odpovědi hledat.

Ve zdrojovém kódu se hodnoty řeší především v souboru objects.h.

Dík moc, zkoušel jsem to studovat před několika měsíci a moc chytrej jsem z toho nebyl, ale teď se znalostma z článku to možná bude už snažší, zkusim se k tomu vrátit.

Měl bych ještě jeden (možná triviální) dotaz: Jak je uděláno, že když se ve v8 vytvářejí třeba stringy:

v8::String::New("blabla")

tak že to je normální funkce a nikoliv metoda nějakýho objektu, který by udržoval tabluky stringů, objektů atd.? tj neco jako

context->NewString("blabla)
nebo
v8::String::New(context, "blabla")


Nebo oni si odkazy na všechny stringy uržovat nepotřebujou (kvůli GC)? (Co kdybych třeba rozjel víc v8 java Interpretrů najednou?)

No, vlastně když je GC kopírující, tak seznam všech objektů na GC nepotřebuju, ale zase potřebuju vědět, jakým alokátorem naalokovat paměť pro ten string, abych mohl pak uvolnit tu oblast, ze které se kopírovalo, ne?

GC obecně potřebují znát pouze "root set": sadu objektů, o kterých je známo, že jsou vždy dosažitelné. To jsou objekty na zásobníku, globální objekty, a tak. V případě generačních GC se to trochu komplikuje, ale to nechme. Tranzitivní uzávěr root set (všechny objekty, na které se z root set lze dostat přes reference) jsou pak "živé" objekty, ostatní lze vyházet. Takže obecně platí, že GC nepotřebuje tabulku všech objektů (to nezávisí na použitém algoritmu).

Uvolňování paměti je zajímavá otázka, to se leckde vůbec neřeší. Třeba Suní JVM co jednou schvátí, to už nenavrátí. Kopírovací algoritmus se obvykle popisuje tak, že alokovaná paměť se rozdělí na dvě části a ty si aplikace spravuje sama, ale zřejmě se dá implementovat i tak, že nová oblast pro objekty se vždycky alokuje znova a ta stará se po zkopírování všech živých objektů dealokuje, jak mi vyplývá z tohoto článku.

Dík za reakci, ale to se mi úplně nezdá. U Mark and Sweep alogoritmu je Mark fáze jasná, ale v té sweep fázi se uvolňují nedosažitelné objekty a pak je nějak potřebuji znát (přinejmenším v některých implementacích), abych je mohl uvolnit. Např. Lua si pro tento účel udržuje slinkovaný seznam objektů (aspoň v té verzi, na kterou jsem se koukal). Jak už jsem psal, pokud je GC kopírovací, tak to je něco jiného. Ale v tom případě existuje jenom jeden globální "alokátor" na objekty?
Nicméně stejně by mě zajímal odpověď na můj původní dotaz, protože absence nějakého kontextu mi připadá záhadná.

Pokud se týká stringů, tak třeba .NET na ně mí spciální zacházení. Zde je odkaz na dokument http://moon.felk.cvut.cz/~xballner/vyuka/x36api/lectures/API_6.pdf.

Ani u mark and sweep algoritmu nepotřebujete vyrábět seznam nedosažitelných objektů. Pokud třeba reprezentujete volnou paměť pro alokátor objektů jako zřetězený seznam volných bloků: v mark fázi označíte živé objekty a ve sweep fázi procházíte celý heap od začátku do konce a každý blok paměti, který nepatří živému objektu (to poznáte podle značky a velikosti každého objektu, která musí být známa), do toho seznamu přidáte. Ten seznam dokonce nemusí být nikde mimo, všechna data (velikost tohoto bloku + ukazatel na následující volný blok) mohou být uložena přímo na místě. Netuším, jak to dělají kucí od Luy, ale čekal bych spíš právě tohle.

Samostatné alokátory pro různé typy objektů – hm, to je zajímavé, to mne nenapadlo. Alokace objektu přece znamená, že se (v nursery) rezervuje určitá část paměti, případně se nějak inicializuje, a reference se někam uloží. S řetězcovými konstantami se třeba dělají různé fígle, ale v principu to na věci nic nemění. Takže mi ani nějak není jasné, proč by něco jako kontext alokace mělo existovat.

Nemyslel jsem samostatné alokátory pro různé typy objektů, ale Javascript "strojů". To, co popisujete v prvním odstavci, je jen jiná forma seznamu nedosažitelných objektů. Jde mi o to, jeslti ve v8 existuje jen jeden heap globální heap. Pokud mám jen jeden globální alokátor (heap), pak nemůžu rozjet vedle sebe víc samostatných Javascript strojů vedle sebe (jinak by měly měly společný heap (a případně další struktury právě nesené nějakým kontextem)).

Aha, rozumím, vlastně celou dobu píšu o něčem jiném :-) Podle toho textu odkázaného níže (Embedder's Guide) je kontext zřejmě implicitní. Představuju si to jako globální zásobník kontextů, přičemž aktivní je ten na vrcholu. Nějaká data ty kontexty určitě sdílejí, ale to je spíš optimalizace (na principu copy on write?), dá se na to koukat tak, že každý kontext má všechno vlastní.

Jo, asi bude vždy aktivní jen jeden, jinak si to taky vysvětlit nedovedu. Zkusím se znovu zanořit do zdrojáků, ale je to trochu nad moje síly.

Pročtěte si Embedder's Guide, lecos je tam vysvětleno a pokud tam nenajdete odpověď, aspoň budete budete tušit, co dál zkoumat. Více kontextů V8 samozřejmě podporuje (je to nutné už kvůli tomu, že je používán v prohlížeči, kde se obecně stránky nesmí navzájem ovlivňovat.

No jasně, já vim, že má, proto mi to vrtá v hlavě. Embedder's Guide jsem četl, ale moc mi to nepomohlo. Dokonce jsem si vytváření nového stringu ve V8 krokoval, ale za chvíli jsem se v tom ztratil.
Každopádně dík za odpovědi i za pěknou sérii.

Ja tedy zvedam ruku, ze mam radeji C ;-)

Za mne také čárku pro C :-)

C si nechajte, ale take C++ s STLkou a boostom... ;) uz iba trochu chrumkavej reflexie :(