Prečo má prvá (m) alokácia C++ vždy 72 KB?

Záhada vašej prvej alokácie C++

Napíšete jednoduchý program v C++. Jeden new int. Štyri bajty. Spustíte strace alebo svoj obľúbený pamäťový profilovač a je to tu – váš proces si práve vyžiadal približne 72 KB od operačného systému. Nie 4 bajty. Nie 64 bajtov. Celých 72 kB. Ak ste niekedy zízali na toto číslo a uvažovali ste, či vám vaše náradie neklame, nie ste sami. Toto zdanlivo bizarné správanie je jednou z najčastejšie kladených otázok medzi vývojármi v C++, ktorí sa prvýkrát zaoberajú internými pamäťami, a odpoveď nás zavedie na fascinujúcu cestu cez vrstvy, ktoré sa nachádzajú medzi vaším kódom a skutočným hardvérom.

Čo sa stane, keď zavoláte nové

Aby ste pochopili číslo 72 kB, musíte sledovať celý reťazec prideľovania. Keď váš kód C++ spustí new int, kompilátor to preloží do volania operator new, ktoré na väčšine systémov Linux deleguje na malloc z glibc. Ale malloc nežiada priamo jadro o 4 bajty pamäte. Jadro funguje na stránkach – zvyčajne 4 KB na x86_64 – a náklady na systémové volanie sú obrovské v porovnaní s jednoduchým prístupom do pamäte. Volaním brk() alebo mmap() pre každú jednotlivú alokáciu by sa zastavil akýkoľvek netriviálny program.

Namiesto toho funguje ako prostredník alokátor pamäte glibc – implementácia s názvom ptmalloc2, ktorá sama pochádza z klasického dlmalloc Douga Lea. Vyžaduje veľké bloky pamäte od jadra vopred a potom ich rozdelí na menšie časti, ako ich váš program potrebuje. Toto je základný dôvod, prečo vaše prvé 4-bajtové pridelenie spúšťa oveľa väčšiu požiadavku na operačný systém. Alokátor neplytvá. Je to strategické.

Rozdelenie 72 kB: Kam idú bajty

Počiatočná réžia prideľovania pochádza z niekoľkých odlišných komponentov, ktoré musí runtime inicializovať predtým, ako vám môže poskytnúť čo i len jeden bajt použiteľnej pamäte. Pochopenie každého komponentu vysvetľuje, prečo sa číslo dostane tam, kde je.

Po prvé, malloc glibc inicializuje hlavnú arénu – primárnu účtovnú štruktúru, ktorá sleduje všetky alokácie v hlavnom vlákne. Táto aréna obsahuje metadáta pre haldu, ukazovatele voľného zoznamu a štruktúry zásobníkov pre rôzne veľkosti alokácií. Alokátor predĺži programovú prestávku pomocou sbrk() a počiatočné rozšírenie sa riadi interným parametrom s názvom M_TOP_PAD, ktorého predvolená hodnota je 128 KB výplne. Skutočná počiatočná požiadavka je však upravená podľa zarovnania stránky a existujúcej pozície prerušenia, čo často vedie k menšej prvej požiadavke – bežne sa blíži k číslu 72 kB na čerstvo začatom procese.

Po druhé, od glibc 2.26 alokátor pri prvom použití inicializuje lokálnu vyrovnávaciu pamäť vlákna (tcache). Cache obsahuje 64 zásobníkov (jeden na triedu veľkosti s malou alokáciou), pričom každý je schopný pojať až 7 blokov uložených vo vyrovnávacej pamäti. Samotný tcache_perthread_struct zaberá približne 1 KB, ale jeho inicializácia spúšťa nastavenie širšej arény. Po tretie, runtime C++ už vykonalo alokácie ešte pred spustením main() – statické konštruktory, inicializácia vyrovnávacej pamäte iostream pre std::cout a priateľov a nastavenie miestneho nastavenia, to všetko prispieva k tejto počiatočnej stope.

Systém arény a prečo je predbežná alokácia inteligentná

Rozhodnutie predbežne prideliť podstatnú časť pamäte namiesto toho, aby ste ju požadovali po kúskoch, nie je náhodná implementácia. Je to zámerný inžiniersky kompromis zakorenený v desaťročiach skúseností so systémovým programovaním. Každé volanie funkcie brk() alebo mmap() zahŕňa prepnutie kontextu z používateľského priestoru do priestoru jadra, úpravu mapovania virtuálnej pamäte procesu a potenciálne aktualizácie tabuľky stránok. Na modernom hardvéri stojí jeden systémový hovor približne 100 – 200 nanosekúnd – triviálne v izolácii, katastrofálne v rozsahu.

Zvážte program, ktorý počas inicializácie vykoná 10 000 malých alokácií. Bez predbežného pridelenia by to znamenalo 10 000 systémových hovorov, čo by stálo približne 1-2 milisekúndy čistej réžie. Pri alokátore založenom na aréne spustí prvá alokácia jediné systémové volanie a následných 9 999 alokácií sa obsluhuje výlučne v užívateľskom priestore prostredníctvom aritmetických ukazovateľov a operácií spojených zoznamov – každá trvá približne 10-50 nanosekúnd. Matematika je jednoznačná: predbežná alokácia vyhráva rádovo.

Tých 72 kB, ktoré vidíte pri prvom pridelení, nie je zbytočná pamäť – je to investícia do výkonu. Alokátor vsádza, že váš program čoskoro pridelí viac alokácií a prakticky v každom scenári reálneho sveta sa táto stávka bohato vypláca. Náklady na nevyužitý priestor virtuálnych adries sú na moderných 64-bitových systémoch v podstate nulové.

Virtuálna pamäť verzus fyzická pamäť: Prečo na tom nezáleží

Spoločným problémom vývojárov, ktorí sa s týmto správaním stretávajú prvýkrát, je plytvanie zdrojmi. Ak potrebujem iba 4 bajty, prečo môj program zaberá 72 KB? Rozhodujúce je, že virtuálna pamäť nie je fyzická pamäť. Keď glibc rozšíri prerušenie programu o 72 KB, jadro aktualizuje mapovania virtuálnej pamäte procesu, ale tieto stránky okamžite nepodporí fyzickou pamäťou RAM. Skutočné fyzické stránky sú prideľované na požiadanie prostredníctvom chyb stránky — iba keď váš program zapisuje na konkrétnu adresu, jadro mu priradí skutočnú stránku pamäte.

To znamená, že aj keď sa virtuálna veľkosť vášho procesu zväčší o 72 kB, jeho veľkosť rezidentnej sady (RSS) – množstvo skutočne spotrebovanej fyzickej pamäte RAM – sa zväčší iba o stránky, ktorých sa skutočne dotknete. Pre jeden new int je to zvyčajne jedna stránka s veľkosťou 4 kB plus akékoľvek stránky, ktoré zaberajú metadáta arény. Zostávajúci virtuálny priestor je pripravený na použitie a nestojí nič iné ako adresný priestor – ktorého máte 128 TB na 64-bitovom systéme Linux.

Tento rozdiel je rozhodujúci pri profilovaní a monitorovaní produkčných aplikácií. Ak vytvárate softvér, ktorý potrebuje sledovať skutočnú spotrebu zdrojov – či už ide o backend SaaS, mikroslužbu alebo analytický kanál, ako sú tie, ktoré fungujú na platformách ako Mewayz pre obchodné operácie – vždy by ste mali monitorovať RSS namiesto virtuálnej veľkosti. Nástroje ako /proc/[pid]/smaps, valgrind --tool=massif a pmap vám môžu poskytnúť presné údaje o fyzickej pamäti namiesto zavádzajúcich údajov o virtuálnej pamäti.

Ako rôzni alokátori zvládajú prvé pridelenie

Číslo 72 KB je špecifické pre ptmalloc2 od glibc. Iní alokátori robia rôzne kompromisy a počiatočná alokačná réžia sa podľa toho mení. Pochopenie týchto rozdielov je cenné pri výbere alokátora pre aplikácie citlivé na výkon.

• jemalloc (používa Facebook, FreeBSD) — Používa podrobnejšiu štruktúru arény s lokálnymi vyrovnávacími pamäťami vlákien. Počiatočná réžia má tendenciu byť vyššia (často 200+ kB), ale poskytuje lepší viacvláknový výkon vďaka zníženému súpereniu o zámky.
• tcmalloc (Google Thread-Caching Malloc) – V predvolenom nastavení prideľuje medzi vláknom cache približne 2 MB s agresívnym predbežným prideľovaním. Počiatočná réžia je vyššia, ale následné malé alokácie sú extrémne rýchle.
• musl libc's malloc — Používa oveľa jednoduchší dizajn založený na mmap pre všetky alokácie. Počiatočná réžia je minimálna (často len 4 kB na pridelenie), ale náklady na pridelenie sú vyššie v dôsledku častejších systémových volaní.
• mimalloc (Microsoft) – Používa segmentové prideľovanie so 64 MB segmentmi. Prvá alokácia spustí virtuálnu rezerváciu 64 MB (s minimálnym fyzickým záväzkom), priestor na obchodovanie s adresou pre výnimočnú lokalitu a priepustnosť.

Výber medzi týmito alokátormi závisí výlučne od vašej pracovnej záťaže. Pre dlhotrvajúce serverové aplikácie s ťažkou viacvláknovou alokáciou jemalloc alebo tcmalloc zvyčajne prevyšuje predvolenú hodnotu glibc. Pre vstavané systémy s obmedzenou pamäťou môže byť napriek nižšej priepustnosti vhodnejší jednoduchší prístup musla. Pre väčšinu všeobecných desktopových a serverových aplikácií predstavuje počiatočná réžia ptmalloc2 72 KB primeranú predvolenú hodnotu, ktorá funguje dobre bez ladenia.

Ladenie počiatočného správania pri prideľovaní

Ak je predvolená počiatočná réžia 72 kB pre váš prípad použitia skutočne problematická – možno vytvárate tisíce krátkodobých procesov, z ktorých každý robí len niekoľko alokácií – glibc poskytuje niekoľko laditeľných možností prostredníctvom mallopt() a rodiny premenných prostredia MALLOC_.

Parameter M_TOP_PAD riadi, koľko pamäte navyše alokátor požaduje nad rámec toho, čo je okamžite potrebné. Nastavenie na 0 pomocou mallopt(M_TOP_PAD, 0) povie alokátorovi, aby požadoval iba to, čo je potrebné, čím sa výrazne zníži počiatočná réžia. Parameter M_MMAP_THRESHOLD riadi veľkosť, nad ktorou alokácie používajú namiesto arény mmap. M_TRIM_THRESHOLD ovláda, kedy sa uvoľnená pamäť vráti do operačného systému. A od verzie glibc 2.26 vám laditeľné položky glibc.malloc.tcache_count a glibc.malloc.tcache_max umožňujú ovládať správanie vyrovnávacej pamäte vlákien.

Pozor: vyladením týchto parametrov bez starostlivého porovnávania sa veci takmer vždy zhoršia. Predvolené hodnoty boli zvolené na základe rozsiahleho profilovania v reálnom svete a predstavujú sladké miesto pre veľkú väčšinu úloh. Pokiaľ nemáte silné dôkazy z profilovania produkcie, že réžia malloc je prekážkou – a nemerali ste vplyv svojich zmien – nechajte predvolené hodnoty na pokoji. Predčasná optimalizácia alokátora je obzvlášť zákerná forma holenia jakov, ktorá spotrebovala nespočetné množstvo inžinierskych hodín na zanedbateľný prínos.

Čo nás to naučí o systémovom programovaní

Záhada prvého pridelenia veľkosti 72 kB je vo svojej podstate lekciou o abstraktných vrstvách. C++ vám dáva ilúziu, že new int alokuje 4 bajty. Hovorí to jazyková norma. Hovorí to váš mentálny model. Ale medzi vaším kódom a hardvérom je hromada sofistikovaných systémov – runtime C++, alokátor knižnice C, subsystém virtuálnej pamäte jadra a hardvérové MMU a TLB – z ktorých každý pridáva svoje vlastné správanie, optimalizácie a réžiu.

Toto nie je chyba. Je to celý zmysel systémového softvéru. Každá vrstva existuje, aby vyriešila skutočný problém: existuje alokátor, takže nemusíte vykonávať systémové volania pre každú alokáciu. Systém virtuálnej pamäte existuje, takže nemusíte priamo spravovať fyzickú pamäť. Obslužný program poruchy stránky existuje, takže pamäť je potvrdená lenivo a efektívne. Každá vrstva vymieňa malé množstvo transparentnosti za veľké množstvo výkonu a pohodlia.

Vývojári, ktorí stavajú najspoľahlivejšie a najvýkonnejšie systémy, sú tí, ktorí rozumejú týmto vrstvám – nie preto, že by na ne potrebovali neustále myslieť, ale preto, že keď sa stane niečo neočakávané (napríklad záhadná alokácia 72 KB), majú mentálny model, aby pochopili prečo. Či už vytvárate obchodný systém v reálnom čase, herný engine alebo obchodnú platformu slúžiacu tisíckam používateľov, schopnosť uvažovať o tom, čo váš kód skutočne robí na systémovej úrovni, je to, čo oddeľuje kompetentných vývojárov od výnimočných. Tých 72 kB nie je chyba. Je to váš alokátor, ktorý robí svoju prácu skvele.