Почестване: финализация и събиране на боклука

Как работи събирачът на боклук

Наприме може да се мисли че хийпът в C++ е нещо като двор, в който всеки обект си заделя негово си местенце. Този недвижим имот може да бъде изо­ста­вен по-късно и повторно използван. В някои JVMашини хийпът на Java е доста раз­личен; той по-прилича на конвейерна лента, която се придвижва напред с вся­ко създаване на обект. Това значи че алокирането на памет е забележително бър­зо. “Хийп указателят” просто се мести напред върху девствена територия, та­ка че ефективно е същото като алокирането в стека в C++. (Разбира се, има мал­ко режийни за счетоводството, но не и търсене в паметта. (И, разбира се, са­ма­та виртуална машина не бива да се забравя при сравняването с С++ - б.пр.))

Може да забележите сега, че хийпът не е конвейерна лента и ако се третира по то­­зи начин ще се получи голямо прехвърляне на страници (страницирането е го­лям пробив в скоростта) и недостиг на страници. Трикът е, че събирачът на бо­клук влиза в ролята си и мести “указателя на хийпа” по-близо до началото на кон­вейера и по-далеч от издънването на програмата вследствие page fault и не­възможност да се излезе от него. Боклучарят реорганизира нещата и прови въз­мож­но прилагането на модела на безкрайния свободен хийп при алокирането на па­мет.

За да разберете как става това, трябва да имате по-добра представа как раз­лич­ни­те боклучарски (GC) схеми работят. Проста но бавна GC техника е броене на по­зо­ваванията. При нея всеки обект има брояч на позоваванията и всеки път ко­гато се присъедини манипулатор към обекта броячът се увеличава. Всеки път когато манипулатор излезе от обхвата или стане null броячът се намалява. Така управ­лението на броячите довежда до малки допълнителни разходи за следене ка­кво става през живота на програмата. Боклучарят преглежда целия списък на обек­тите и когато намери обект с брояч сочещ нула освобождава паметта му. Единия недостатък е, че понеже обектите може да се позовават един на друг и са­ми на себе си може да се случи броячът да не е нула, а обектът да си е за из­чист­ване. Улавянето на такова самопозоваване изисква значителна до­пъл­ни­тел­на работа от боклучаря. Броенето на позоваванията често се използва за обяс­ня­ване на събирането на боклука но не изглежда да се използва в много реа­ли­за­ции на JVM.

При по-бързи схеми събирането не е основано на броене на позоваванията. Вмес­то това се използва идеята че от всеки жив (продължаващ да бъде из­полз­ван) обект може да се проследи път до валиден манипулатор или на стека или в ста­тична памет. Веригата може да върви през няколко слоя обекти. Така ако про­следите всички манипулатори които са на стека и в статичната памет ще стиг­нете и до всички живи обекти. За всеки манипулатор трябва да се проследи пъ­тя до обекта и след това да се видят манипулаторите в обекта, които ще до­ве­дат до други обекти, и т.н., докато се обхване цялата паяжина започваща от спо­менатия манипулатор на стека или в статичната памет. Всеки срещнат по пъ­ти­щата обект сигурно е жив. Забележете, че няма проблем със самозатворени гру­пи — те просто не се броят въобще и биват почиствани целите.

При описания подход JVM използва адаптина схема за събиране на боклука и това което се прави с живите обекти зависи от конкретната текуща кон­фи­гу­ра­ция. Един от вариантите е спри-и-копирай. Тоест по причини които по-късно ще станат ясни, програмата първо се спира (тази не е фонова схема за събиране на боклука). После всеки намерен жив обект се копира в друг хийп, а старата па­мет се освобождава цялата. В добавка, понеже се копират на ново място, обек­тите се разполагат един до друг, т.е. новата памет е компактно заета (и ста­ра­та памет изцяло, т.е. бързо, се освобождава, както вече се спомена).

Разбира се, когато обект се мести на друго място всички манипулатори които го сочат трябва да се променят. Лесно се променя първоначалният ма­ни­пу­ла­тор, но има и други манипулатори които могат да сочат към обекта и те да се от­крият по време на “разходката.” Те се променят когато бъдат намерени (можем да си представим една таблица която изобразява старите адреси в но­ви­те).

Има две неща които правят тези тъй наречени “copy collectors” (копиращи боклучари, във възприетата в превода терминология - б.пр.) неефективни. Пър­вото е, че има два хийпа и обектите се преточват от единия в другия, на прак­тика използвайки два пъти повече памет. Някои JVMашини се оправят с то­ва като алокират памет на порции и работят с тях, а алокират нови само ако е не­об­ходимо.

Второто е копирането. Веднъж като се стабилизира програмата може да ге­не­ри­ра малко или никакъв боклук. Напук на това копи боклучарят ще продължи да ко­пира всичко от една място на друго, което е прахосничество. За да пре­дотвра­тят това някои JVMмашини детектират когато не се прави нов боклук и пре­включват на друга схема (това е “адаптивната” част). Тази друга схема се на­рича mark and sweep и тя е която се използваше през цялото време в ранните вер­сии на виртуалната машина на Sun. За обща употреба схемата "маркирай и из­мети" е доста бавна, но когато не се генерира много или въобще боклук тя е мно­го добра.

"Маркирай и измети" следва същата логика на проследяване на обектите както пре­ди. Обаче при намиране на жив обект в него се установява флаг, с което той се отбелязва, но още не се прави почистването. То става чак като завърши про­це­сът на маркирането. По време на метенето мъртвите обекти се освобождават. Не се прави и компактинг, обаче, така че ако боклучарят иска да уплътни па­мет­та ще го направи в отделен пас.

Името “спри и копирай” е свързано с идеята че събирането на боклука не е фо­нов процес; програмата е спряна пре време на GC. В литературата на Sun може да се намерят много споменавания на събирането на боклука като фонов про­цес с нисък приоритет, но изглежда че това е било теоретичен експеримент без реа­лизация, най-малкото не в ранните версии на JVM на Sun. Вместо това бо­клу­чарят на Sun се задействаше при недостиг на памет. В добавка, "маркирай и из­мети" изисква спиране на програмата.

Както се спомена по-рано, във JVM описвана тук паметта се заема на големи бло­кове. Ако се алокира голям обект той взема свой собствен блок. Стриктното спри-и-копирай изисква копирането на всеки жив обект на новото място преди да може да се освободи старото, което резултира в много памет. С боковете GC ти­пично може да използува мъртвите блокове за копиране в трях в процеса на ра­бота. Всеки блок има брояч на поколението за да се знае дали е жив. В нор­мал­ния случай само блоковете създадени след последния GC се сгъстяват; всич­ки останали отбелязват с брояча си ако на тях има позоваване от някъде. То­ва обслужва нормалния случай на множество късоживеещи обекти. Пе­рио­дич­но се прави пълно измитане – големите обекти още не са копирани и бло­ко­ве­те къито съдържат малки обекти са копирани и сгъстени. JVM следи ефек­тив­ност­та на GC и ако то се окаже загуба на време защото повечето обекти са дъл­го­живеещи, превключва се на маркирай-и-измети. Подобно JVM ,следи до­кол­ко е ефективно маркирай-и-измети и ако хийпът се фрагментира се превключва обрат­но на спри-и-копирай. Това е мястото където работи “адаптивната част”, така че завършваме на един дъх с фразата: “адаптивна генерационна спри-и-ко­пи­рай маркирай-и-измети.”

Има и други допълнителни възможности за ускоряване в JVM-та. Една особено важ­­на включва лоудера и Just-In-Time (JIT) компилатора. Когато трябва да се на­то­вари клас (типично: когато за пръв път ще се създава обект от този клас), .class файлът се намира и кодът се качва в паметта. В тази точка еденият под­ход е просто да се JIT всичкия код, но това има два недостатъка: заема малко по­вече време, което по продължение на програмата може да се натрупа; и уве­ли­чава дължината на изпълнимия модул (байт кодовете са значително по-ком­пакт­ни от разширения JIT код) и така може да се предизвика пейджинг, което опре­делено забавя програмата. Алтернативен подход е мързеливият, което зна­чи че кодът не се JIT компилира докато това не стане необходимо. Така кодът който ни­ко­га не се изпълни може и никога да не се JIT компилира.