abclinuxu.cz AbcLinuxu.cz itbiz.cz ITBiz.cz HDmag.cz HDmag.cz abcprace.cz AbcPráce.cz
AbcLinuxu hledá autory!
Inzerujte na AbcPráce.cz od 950 Kč
Rozšířené hledání
×
eParkomat, startup z ČR, postoupil mezi finalisty evropského akcelerátoru ChallengeUp!
Robot na pivo mu otevřel dveře k opravdovému byznysu
Internet věcí: Propojený svět? Už se to blíží...
včera 11:00 | Bezpečnostní upozornění

Greg Kroah-Hartman vydal nová vanilla linuxová jádra 4.6.3, 4.4.14 a 3.14.73. Řešeny jsou mimo jiné dva bezpečnostní problémy CVE-2016-4997 (lokální eskalace práv) a CVE-2016-4998 (přístup do paměti mimo hranice alokované paměti) [reddit].

Ladislav Hagara | Komentářů: 1
včera 11:00 | Komunita

Byla vydána verze 2.5.2-1 linuxového prostředí pro operační systémy Windows Cygwin (Wikipedie). Z novinek lze zmínit přelicencování knihovny Cygwin z GPLv3 na LGPLv3. Podrobnosti na blogu společnosti Red Hat [reddit].

Ladislav Hagara | Komentářů: 0
24.6. 16:16 | Nová verze

Eclipse Foundation oznámila vydání nové verze vývojového prostředí Eclipse. Eclipse 4.6 s kódovým označením Neon vychází rok po vydání verze 4.5 s kódovým označením Mars (zprávička) a přináší celou řadu novinek. Jejich představení také na YouTube.

Ladislav Hagara | Komentářů: 1
24.6. 10:38 | Nová verze

Vyšel oVirt 4.0, open source virtualizační rozhraní pro KVM. Novinek je opravdu hodně, namátkou třeba vylepšená live migrace, nový administrační portál (Cockpit), vylepšená práce s libvirt obrazy, podpora Atomic guest OS, vylepšené API (vylepšený výkon + přibylo sdk pro ruby), hotplug SR-IOV vNIC u spuštěné VM. Kompletní seznam změn viz : release notes.

Max | Komentářů: 0
24.6. 00:11 | Nová verze

Po 8 měsících od vydání verze 4.6 byla vydána verze 4.7 virtualizačního softwaru Xen. Z novinek lze zmínit například Live Patching. Podrobnosti v poznámkách k vydání, přehledu nových vlastností a porovnání s předchozími verzemi.

Ladislav Hagara | Komentářů: 0
23.6. 21:00 | Komunita

Otevřená certifikační autorita Let's Encrypt informuje, že musí bránit název Let's Encrypt. Comodo Group se snaží registrovat ochranné známky Let’s Encrypt, Let’s Encrypt With Comodo a Comodo Let’s Encrypt. Žádosti byly podány v říjnu 2015. Certifikační autorita Let's Encrypt byla představena v listopadu 2014 (zprávička).

Ladislav Hagara | Komentářů: 5
23.6. 18:48 | Zajímavý článek

HackerBoards.com (ještě nedávno LinuxGizmos.com) zveřejnil výsledky čtenářské ankety o nejoblíbenější jednodeskový počítač (SBC) v roce 2016. Letos se vybíralo z 81 jednodeskových počítačů (pdf) (vloni to bylo 53, předloni 32). Nejoblíbenějšími jednodeskovými počítači v letošním roce jsou Raspberry Pi 3 Model B, Odroid-C2 a BeagleBone Black.

Ladislav Hagara | Komentářů: 0
23.6. 17:06 | Zajímavý projekt

Indiegogo kampaň na rozšiřující desku pro použití Raspberry Pi v průmyslových aplikacích - Monarco HAT - se blíží ke konci. Vybralo se zatím 92 % z cílových 10 000 EUR a do konce zbývají už jen 4 dny. … více »

VSi | Komentářů: 1
23.6. 13:53 | Zajímavý projekt

Jedním z cílů otevřené certifikační autority Let's Encrypt je zcela nahradit HTTP protokolem HTTPS. V příspěvku na blogu autority je hodnocen dosavadní stav. Při spuštění veřejné bety v prosinci 2015 (zprávička) bylo pomocí HTTPS stahováno 39,5 % webových stránek (měřeno pomocí Firefox Telemetry). Dnes je to 45 %. Certifikační autorita Let's Encrypt vydala od prosince více než 5 milionů certifikátů. Aktivních je 3,8 milionu certifikátů. Chráněno pomocí Let's Encrypt je více než 7 milionů unikátních domén.

Ladislav Hagara | Komentářů: 12
23.6. 00:11 | Komunita

Mozilla na svém blogu informuje, že z fondu Mission Partners, jenž je součásti programu Mozilla Open Source Support (MOSS), bylo uvolněno 385 000 dolarů. Tyto peníze byly rozděleny mezi 8 projektů: Tor, Tails, Caddy, Mio, DNSSEC/DANE Chain Stapling, Godot Engine, PeARS a NVDA.

Ladislav Hagara | Komentářů: 0
Jaký poměr stran pracovní plochy (příp. složené z více monitorů) preferujete?
 (7%)
 (13%)
 (52%)
 (21%)
 (4%)
 (2%)
 (1%)
Celkem 525 hlasů
 Komentářů: 30, poslední 11.6. 16:07
    Rozcestník
    Reklama

    Správa paměti v Mac OS X

    15.9.2009 20:30 | Přečteno: 3977× | Apple | Výběrový blog | poslední úprava: 15.9.2009 20:40

    Správa paměti v Mac OS se dost liší od Windows, Linuxu nebo dokonce BSD a současně se dost obtížně shánějí relevantní informace na toto téma. Myslím, že tedy bude užitečné shrnout ve zkratce známá fakta a současně tím třeba i vyvrátit několik mýtů, kterými je celá záležitost opletena.

    Nejdříve krátká odbočka k získávání detailních informací o jádře Mac OS. Jediným spolehlivým zdrojem je kniha Mac OS X Internals - A Systems Approach a i ta bohužel už trochu zastarala. Dále se dá občas něco pochytit od vývojářů, kteří metodou pokus-omyl nějaké informace zjistili. Doporučuji např. video přednášky jednoho z vývojářů VMWare Fusion (prvních 14 minut marketingových keců můžete směle přeskočit). Dokumentace od Applu je velmi povrchní, zavádějící, nepřesná a občas se vyloženě "míjí s pravdou". Situace je opravdu katastrofální, nesrovnatelně horší než v případě Linuxu nebo dokonce Windows.


    Podívejme se na výstup vm_stat

    Mach Virtual Memory Statistics: (page size of 4096 bytes)
    Pages free:                          79657.
    Pages active:                      2440855.
    Pages inactive:                     633605.
    Pages speculative:                  650414.
    Pages wired down:                   389994.


    Čísla jsou v 4 kiB stránkách, ta potvornost nemá žádný přepínač, kterým by se dala přinutit ukazovat v jiných jednotkách. Free je prostě volná paměť, kterou je možno ihned použít bez jakýchkoliv dalších operací. Seznam volných stránek je uložen ve FIFO kontejneru, tedy ve frontě.


    Speculative je volná paměť, která je naplněná přednačenými daty (v tomto případě téměř 2,5 GiB, nepodařilo se mi zjistit jaký mechanismus se používá ale nepředpokládám, že by se tolik místa zaplnilo prostým read-ahead přístupem. Navíc tato paměť hned po bootu prudce roste). Táto data byla přednačtená ale nikdy k nim nebylo přistoupeno, v takovém přsípadě by spadly do active/inactive kolotoče, o kterém za chvíli. GUI aplikace reportují volnou paměť jako součet free + speculative.


    Wired paměť je zamknutá ve fyzické paměti- nelze ji odstránkovat. Je zde zejména paměť jádra ale běžný proces si o zamčení oblasti paměti voláním mlock může zažádat také (Linux má obdobné volání také, ve Windows lze správci paměti pouze doporučit aby nějakou oblast ponechal v paměti, není to však závazné a nelze s tím tedy počítat což má určité implikace pro realtime aplikace a aplikace, kde by případne odstrankování mohlo být bezpečnostním problémem. Ve windows je vlastně i podstatná část paměti jádra stránkovatelná... ale to je zase na jiný článek :-) ). Některé aplikace mlock používají, zejména Parallels a VMWare takto zamykají obrovské bloky paměti. Z výpisu výše je vidět takřka 1.5 GiB zamčené paměti protože tam běží ve VMWare stroj s přidělenou pamětí 1 GiB. Wired paměť má v Mac OS jednu specialitu - nevrací se po uvolnění ihned do free poolu ale stane se tak až když volná paměť dojde nebo množství wired paměti přesáhne nějakou hranici. Plyne to z maximálně líného přístupu ke správě paměti řídicího se heslem- pokud je volná paměť tak na nic nesahej. To je v ostrém kontrastu k „hyperaktivní“ správě paměti ve Windows. Linux je z tohoto hlediska někde uprostřed. Wired paměť nemá svoji frontu stránek a tyto stránky jsou pochopitelně vyřazeny ze všech jiných zde zmiňovaných front. Srovnejte teď co uvádí oficiální vývojářská dokumentace od Apple ( Applications, frameworks, and other user-level software cannot allocate wired memory. ) a jaká je realita např. pomocí tohoto triviálního prográmku


    #include < stdlib.h>
    #include < stdio.h>
    #include < sys/mman.h>
    
    
    int main(void) {
    	int *i = (int*)calloc(1024,1024*1024);
    	printf("%d\r\n",mlock(i,1024*1024*1024));
    	getchar();
    	return 0;
    }

    , který naalokuje 1 GiB paměti a zamkne ji a wired krásně povyskočí právě o 1 GiB nahoru.


    Active je paměť která je mapovaná nějakým procesem. Je zde paměť anonymní (tedy paměť, která není svázaná s žádným souborem na disku, tedy vzniklá zejména voláním malloc nebo mmap s MAP_ANON flagem) i neanonymní. Seznam aktivních stránek je udržován ve frontě.


    Inactive jsou stránky, které nejsou mapovány žádným procesem (většinou následkem toho, že správce paměti toto mapování odebral, o tom ale později). Existují dvě fronty „neaktivních“ stránek- pro anonymní a neanonymní stránky. Inactive stránky mohou být „špinavé“ (dirty stránky jsou takové, které je nutno zapsat na disk předtím, než mohou být odstraněny z paměti, pro anonymní paměť to znamená, že obsah stránky v paměti a ve swapu se liší případně stránka svůj obraz ve swapu doposud vůbec nemá).


    Součet free, active, inactive, speculative a wired dá dohromady celou dostupnou paměť počítače (± pár stovek kiB, které popravdě nevím odkud se berou, že by čtení těch statistik nebylo atomické?), tedy v případě výše uvedeného příkladu 16 GiB. Jak vidíte ve výpisu vm_stat není žádná položka typu cache, buffers ani nic podobného. Mac OS si žádný přehled stránek tohoto typu nevede. Věci, které na Linuxu obstarává SLAB jsou rozpuštěny někde ve wired paměti a cache je zase rozeseta po active a inactive paměti.


    Myšlenka je taková, že v active má být pracovní sada všech spuštěných procesu od jejich kódu přes knihovny až po data, nad kterými pracují (z každé z těchto oblastí samozřejmě jen stránky, které se využívají), inactive je oblast, použité paměti, která ale nepatří do současné pracovní sady ale existuje určitá pravděpodobnost, že bude znovu potřebná. Uměním je (někteří suchaři tomu říkaji heuristika ;-) ) zvolit poměr mezi active a inactive a algoritmus přehazování stránek mezi nimi tak, aby se minimalizoval počet zápisu a čtení stránek z/na disk. Jak je to tedy řešeno v MacOS?


    Jak už jsem naznačil výše- správce paměti je v MacOS líný jak to jen jde. Když je volná paměť tak se stará jen o to, aby přiděloval volnou paměť (bere z free fronty a dává do inactive) procesům a po jejich ukončení vrátí anonymní paměť do free a neanonymní přesune do inactive pokud tam už není. Když proces sáhne na svojí stránku, která je v inactive paměti tak vyvolá soft page fault, stránka se přidá na konec active fronty. A to je vše.


    Když volná paměť dojde (resp. klesne pod určitou úroveň, která se odvodí od celkové velikosti paměti) tak se teprve začne projevovat. Zjistí, zda není volná wired paměť a případně ji vrátí do free fronty. Následně začne přesouvat paměť z active do inactive fronty a to tak, že bere stránky ze začátku active fronty, odstraní její mapování v procesech a přidá je na konec inactive fronty. Nevyužívá se tedy žádný mechanismus stárnutí stránek resp. LRU, žádný zvýhodnění pro interaktivní/aktivní procesy ani nic podobného. Každá nezamčená stránka každého procesu se dříve nebo později dostane do jedné z inactive front.


    Dále provádí čištění stránek v inactive frontě a bere stránky ze začátku inactive fronty a vyhazuje je z paměti. Opět se postupuje výlučněs principem FIFO. O samotné stránkování se pak stará několik specializovaných rutin (samostatně pro výměnu stránek mezi swapem a pamětí, mezi blokovým zařízením a pamětí, …). O vytváření souborů, do kterých se swapuje se stará samostatný proces (dynamic_pager), který se stará, aby se zaplnění swapovacích souborů pohybovalo v rozmezí nastaveném parametry high a low watermark.


    Inactive a active fronty realizují jako celek algoritmus, kterému se přezdívá FIFO with second chance. Jinými slovy každá stránka někdy spadne do inactive ale než probublá inactive frontou až do stavu, že bude odstraněná má šanci, že když se znova použije tak se zařadí na konec fronty active.


    Algoritmus je tedy relativně jednoduchý, důležité ale je jak se to v praxi chová. Když se dostane systém do úzkých tak začne nezadržitelně trashovat. Všechny procesy mají šanci se trochu projevit než probublají celým kolotočem front a žádný vyloženě nehladoví nicméně většina úsilí je stále vynakládaná na neustále odkládání a načítání stránek. Linux se svým swap tokenem je na tom podstatně lépe. V situaci, kdy se working set pohodlně vejde do paměti se projeví další vlastnost- velká ochota nahradit stránky chvíli nečinného procesu stránkami diskové cache. Jinými slovy- chová se to podobně jako Linux s velmi vysoko nastaveným parametrem SWAPINESS. Tento jev je opravdu velmi silný a dá se mu zabránít jen čtením souboru např. přes mmap s flagem MAP_NOCACHE (ten by se dost hodil i v linuxu ale to zase odbíhám) ale nikde se o tom pořádně nedozvíte a přečtením velkého souboru přes fopen a fread si vyhodíte z paměti běžící aplikace na úkor diskové cache.


    Mac OS zkrátka zbožňuje paměť a z výše napsaného je myslím zřejmé proč tomu tak je :) K tomu navíc přispívá i to, že samotné jádro a základní aplikace pamětí příliš nešetří. Pokud sečtu RSS procesů kernel_task, mds, WindowServer, coreServicesd,... tedy takových, které jen zajišťují chod systému a grafického prostředí, na svém počítači tak se dostanu k úctyhodné hodnotě 1,7 GiB.

           

    Hodnocení: 100 %

            špatnédobré        

    Tiskni Sdílej: Linkuj Jaggni to Vybrali.sme.sk Google Del.icio.us Facebook

    Komentáře

    Vložit další komentář

    Jardík avatar 16.9.2009 00:43 Jardík | skóre: 40 | blog: jarda_bloguje
    Rozbalit Rozbalit vše Re: Správa paměti v Mac OS X
    Windows lze správci paměti pouze doporučit aby nějakou oblast ponechal v paměti, není to však závazné a nelze s tím tedy počítat což má určité implikace pro realtime aplikace a aplikace
    Nesouhlasím, ve Windows můžete naalokovat fyzickou paměť a nic vám ji neveme.
    Věřím v jednoho Boha.
    16.9.2009 13:09 miho | skóre: 21 | blog: Mihovy_sochory | Orlová
    Rozbalit Rozbalit vše Re: Správa paměti v Mac OS X

    Oops, to jsem neznal, clovek se uc cely zivot :) Na druhou stranu tohle se asi neda v normalnim softu urcenem pro bezneho smrtelnika pouzit kvuli nutnosti nastavit prava.

     

    17.9.2009 14:06 Miloslav Ponkrác | blog: miloslavponkrac
    Rozbalit Rozbalit vše Re: Správa paměti v Mac OS X

    To je ale správné. Běžný programátor ani program by neměl tyhle akci vůbec umět. Na tu by měl sahat jenom ten, kdo ví co a proč to dělá.

    Upřímně, čím méně hacků dovolí běžný desktopový systém, tím jenom lépe.

    17.9.2009 17:01 Tom K | skóre: 20
    Rozbalit Rozbalit vše Re: Správa paměti v Mac OS X
    Chcete říct, že "normální" SW by neměl se snažit, aby použité klíče nebyly k nalezení odswapované na disku ? (že je celkem normální, aby i desktopový SW šifroval je předpokládám bez diskuse).
    echo -n "u48" | sha1sum | head -c3; echo
    18.9.2009 14:11 podlesh | skóre: 37 | Praha
    Rozbalit Rozbalit vše Re: Správa paměti v Mac OS X
    Ovšem ta feature je určena k něčemu jinému a použít ji pro bezpečné ukládání hesel je jen hack.
    Jardík avatar 16.9.2009 00:50 Jardík | skóre: 40 | blog: jarda_bloguje
    Rozbalit Rozbalit vše Re: Správa paměti v Mac OS X
    základní aplikace pamětí příliš nešetří
    Tohle by mohlo být přítomností GC v objective-c, v němž je psána většina GUI programů.
    Věřím v jednoho Boha.
    16.9.2009 09:10 alblaho
    Rozbalit Rozbalit vše Re: Správa paměti v Mac OS X

    ObjC IMHO nemá pořádný GC, pokud vím, tak je v knihovně jenom zabudovaný reference counting. (A dost by mě zajímalo, jak se to chová na víceprocesorovém systému.)

    No a taky si matně vybavuju, že Apple inicioval nějakou novou verzi ObjC, možná, že tam je to jinak.

    Milan Lajtoš avatar 16.9.2009 00:52 Milan Lajtoš | skóre: 22 | blog: /blog/babraq
    Rozbalit Rozbalit vše Re: Správa paměti v Mac OS X
    Skvelé čítanie!

    Mám dve otázky. Líši sa nejako nejako správa pamäte v Mac OS X a v Darwine? Porovnať kód je nemožné, takže asi len čo sa týka testov a správania. A ešte druhá - existuje v Darwine/OS X niečo ako OOM-killer na Linuxe?
    “Every great achievement was once considered impossible.”
    Jardík avatar 16.9.2009 12:46 Jardík | skóre: 40 | blog: jarda_bloguje
    Rozbalit Rozbalit vše Re: Správa paměti v Mac OS X
    Já myslel, že darwin je jádro MacOS??
    Věřím v jednoho Boha.
    16.9.2009 12:58 miho | skóre: 21 | blog: Mihovy_sochory | Orlová
    Rozbalit Rozbalit vše Re: Správa paměti v Mac OS X

     Ono je to takove trosku komplikovane, Darvin je operacni system postaveny nad hybridnim jadrem, kteremu se prezdiva XNU, ktere je slozene z Mach, na ktery jsou nalepene kusy BSD ak tomu je jeste priplacnuty I/O Kit. 

    Milan Lajtoš avatar 16.9.2009 14:14 Milan Lajtoš | skóre: 22 | blog: /blog/babraq
    Rozbalit Rozbalit vše Re: Správa paměti v Mac OS X
    Jadro nie, skôr základ.

    No, ale k veci - Darwin je základ pre Mac OS X, ale neverím, že by si Apple v ňom neporobilo zmeny. Veď to by bolo ako distribuovať vanilla linux. ;)
    “Every great achievement was once considered impossible.”
    18.9.2009 15:26 eoj
    Rozbalit Rozbalit vše Re: Správa paměti v Mac OS X
    Ach jo...
    16.9.2009 13:04 miho | skóre: 21 | blog: Mihovy_sochory | Orlová
    Rozbalit Rozbalit vše Re: Správa paměti v Mac OS X

    Teoreticky by se to lisit nemelo ale osobni zkusenosti s darvinem nemam. Zminku o ekvivalentu OOM killera jsem nenasel. Vzhledem k tomu, ze se implicitne swapuje do souboru, ktere se dynamicky vytvareji za behu na korenove partition tak by pri zaplneni disku mohlo dojit k zajimavym jevum. Urcite vyzkousim :-)

     

    default avatar 16.9.2009 16:32 default | skóre: 22 | Madrid
    Rozbalit Rozbalit vše Re: Správa paměti v Mac OS X

    To ti řeknu docela přesně, co se stane, když dojde místo na disku pro swap. Běží to zoufale pomalu, nejde nic spustit a aplikace buď na akce nereaguje, nebo jde do beach-ballu. :-D Žádnej crash se nekoná. :-D Je na uživateli, aby paměť uvolnil. Ale stalo se mi to jen na Tigeru. Jak reagují Leopard se Snow Leopardem — to netuším.

    16.9.2009 21:51 Tomáš Srnka | skóre: 7 | Bratislava/Praha
    Rozbalit Rozbalit vše Re: Správa paměti v Mac OS X
    vyskusam, dam vediet ;-) zatial mam 10.5.X, buduci tyzden pojdem na 10.6
    17.9.2009 12:27 ..
    Rozbalit Rozbalit vše Re: Správa paměti v Mac OS X
    je to tak aj u Leoparda, u Snow Leoparda sa mi to este nepodarilo :)
    16.9.2009 09:30 9002
    Rozbalit Rozbalit vše Re: Správa paměti v Mac OS X

    Tesim sa na kombinaciu Étoilé a PureDarwin. Niečo ako OpenMacOS :-)

    skywaker avatar 16.9.2009 13:10 skywaker | skóre: 26 | blog: Lukove | Prešov
    Rozbalit Rozbalit vše Re: Správa paměti v Mac OS X

    ahoj. ja tiež sa tesim na nieco take ale otazka je pouzitelnost takeho niecoho.. maju vobec vyvojary PureDarwina snahu o integraciu etoile? pise sa to niekde? inac zatial je moj favorit Linux a po nom Haiku.

     

    Donate Bitcoins to Luko: 14mXEWw9tgTtRT35RSvLL27XSpyety8x3N
    rADOn avatar 16.9.2009 11:05 rADOn | skóre: 44 | blog: bloK | Praha
    Rozbalit Rozbalit vše Re: Správa paměti v Mac OS X
    Pokud sečtu RSS procesů kernel_task, mds, WindowServer, coreServicesd,... tedy takových, které jen zajišťují chod systému a grafického prostředí, na svém počítači tak se dostanu k úctyhodné hodnotě 1,7 GiB.
    Pokud RSS je totez jako v linuxu tak je cislo na houby. Pokud ne, porad je cislo na houby.

    Napoveda: pamet mapovana z hw. Pust si v X nejakou hezkou hru a vmsize xserveru vyskoci o stovky mega. Dokonce se mi kdysi kasal jeden kamarad jak je UT2004 skvele napsany ze bere jen 36M fyzicky :-) Bodejt by taky ne, kdyz vsechny textury sly na ucet Xserveru… Bezne se to samozrejme nepozna, ale hry a systemovy procesy nejsou tak uplne bezny.
    "2^24 comments ought to be enough for anyone" -- CmdrTaco
    16.9.2009 13:36 miho | skóre: 21 | blog: Mihovy_sochory | Orlová
    Rozbalit Rozbalit vše Re: Správa paměti v Mac OS X

     O RSS a obecne o problematice obsazeni pameti procesem jsem psal zde: http://www.abclinuxu.cz/blog/Mihovy_sochory/2007/9/jak-vam-kyne-linux takze sebestredne a nafoukane predpokladam, ze to kazdy zna a vi, co si pod tim ma predstavit! ;-)

     

    stativ avatar 16.9.2009 11:29 stativ | skóre: 54 | blog: SlaNé roury
    Rozbalit Rozbalit vše Re: Správa paměti v Mac OS X
    A co je nejhorší, že dochází k nechutné fragmentaci paměti.
    Ať sežeru elfa i s chlupama!!! ljirkovsky.wordpress.com stativ.tk
    16.9.2009 15:57 M. Lox | skóre: 12
    Rozbalit Rozbalit vše Re: Správa paměti v Mac OS X
    To jo, TLSF ruluje.
    make menuconfig, not war!
    Snilard avatar 21.9.2009 19:14 Snilard | skóre: 3 | blog: Zápisky Ještěrky | Praha
    Rozbalit Rozbalit vše Re: Správa paměti v Mac OS X

     Jelikož se moc ve správě paměti a alokování v céčku nevyznám, ptám se. Co to pro mne jako uživatele, java, python a snad cocoa programátora znamená?

    Znamená to, že si z naprosto zaplněné paměti nemám nic dělat a dokud to nezačne divoce swapovat, není důvod kupovat víc paměti? Můžu nějak systému s pamětí pomoci?

    Jsem velký zlý itčko. Jestli budeš zlobit, dostaneš přednášku o Hilbertových prostorech.
    stativ avatar 21.9.2009 19:43 stativ | skóre: 54 | blog: SlaNé roury
    Rozbalit Rozbalit vše Re: Správa paměti v Mac OS X
    To, že se v OS X můžeš setkat s prapodivnými chybami (zejména nepodařené větší alokace) které jinde neuvidíš ;-)
    Ať sežeru elfa i s chlupama!!! ljirkovsky.wordpress.com stativ.tk
    Algi avatar 22.9.2009 08:47 Algi | skóre: 1 | blog: Sinner
    Rozbalit Rozbalit vše Re: Správa paměti v Mac OS X

     Nikdy jsem si nevšiml, že by se logovalo něco o prapodivných chybách v alokaci. Naopak si všímám v logu prasáren, které někteří programátoři dělají když neumí používat NSAutoreleasePool či leakujou paměť. O tom, že existuje Leaks a Instruments asi nevědí...

    Jinak jako programátora v Javě ani v Cocoa tě při dodržování správných zásad nemusí nic trápit. Nevím, jak je tomu u "velkých" aplikací, co potřebují hodně paměti. Do zdrojáků Lightroomu nevidím a zbytek je nenáročný, takže pohoda. Ale třebas jsem jenom naivka, co nevidí pod kapotu ;-)

    I'm a firestarter, twisted firestarter...

    Založit nové vláknoNahoru

    ISSN 1214-1267  
    © 1999-2015 Nitemedia s. r. o. Všechna práva vyhrazena.