ol' school & back to basics, «it's a unix system, I know this!» ..
https://www.youtube.com/watch?v=dFUlAQZB9Ng
YouTubesom ledd av evige omskrivingen av ncurses/konsoll RSS-leseren min skrevet i python har jeg nå en ond plan om å fjerne all threading og kun bruke fork() for alle parallelle funksjoner, og named pipes for IPC og synkronisering, så select() for å håndtere all input og i/o eventer i et nytt eget UI-bibliotek. hårete mål - gjerne mot strømmen - er halve moroa..
poenget mitt er at PyPY, som forsøker være en fullstendig Python-implementering av Python (språk som har en kompilator skrevet i samme språket den skal være kompilator for er kompilator-nirvana), ikke bør ha en ha så annen søppeltømming enn CPython så sedvanlig kode knekker uforutsigbart, spesielt når man selger inn PyPY som 'kompatibel raskere python' og utviklerne selv kommer med 'fiks heller koden din' når det påpekes. det er å fornekte virkeligheten. takk for meg,
annet som alle tilfeller av 'mark-and-sweep' også feiler stort på er når man har enormt med minne og allokerer mye av det dynamisk, dette pleide aldri være et problem på 80/90-tallet men i moderne miljøer kan man ha TB med minne. 'smarte' søppeltømmere vil da tillate masse bruk av minne av døde objekter men ikke blande seg inn før man har brukt så mye at det faktisk trengs ryddes, hence får man 'garbage collection stalls', spør Skatteetaten og Altinn skrevet i Java hvordan det kan gå galt...
men PyPy derimot har _ikke_ en deterministisk søppeltømmer, fordi den vil gjøre ting 'riktig' (og at den oversetter RPython ned til C-kode og senere JIT kompilerer ting med awesome magi), så 's = open(f).read()' blir _ikke_ ryddet med en gang. har du noe som sjekker en fil for ny info i en loop, kan du risikere få _mange_ åpne filobjekt i minnet før søppeltømmeren rekker rydde og programmet feiler med 'too many files open'. dette er et eksempel, det finnes _mange_ fler.
fordi CPython har deterministisk søppeltømming - selv med en veldig stor kjent svakhet - er den forutsigbar. som det er veldig enkelt for selv en nybegynner forstå når noe går galt, derfor har man i python ofte idiomer som 's = open(file).read()' som alltid vil virke, selv om man vet at man burde eksplisitt lukke filen med en close(), løse objekter vil ryddes (og filen lukkes) automatisk så snart statementet er ferdig.
informatikere vil fremdeles påstå at ikke-deterministisk søppeltømming ikke er problemet, og løsningen er bare finne bedre algoritmer for å bestemme når den skal kjøre, selv om ingen har greid løse utfordringen på 40+ år, Einstein har et sitat rundt galskapen på den troen.
problemet med 'mark-and-sweep' søppeltømming er selvfølgelig at den er ikke-deterministisk, altså at programmereren aldri vet _når_ den vil kjøre, man må stole på at den kjører når det er 'fornuftig', men det store problemet er å forutsi når denne tidspunktet 'fornuftig' er, og som de fleste med avansert kode som skal kjøre over tid i et stort miljø har erfart, det er bare et tidsspørsmål når 'fornuftig' passer veldig dårlig og tar ned tjenesten din midlertidig.
av alle metoder for søppeltømming i programmeringsspråk har referanse-telling alltid vært sett ned på som 'naivt', og det har alle som har studert informatikk blitt fortalt i over 30 år, 'riktig' metode er en eller annen form for 'mark-and-sweep'
en søppeltømmer som bare teller referanser har en stor, men ganske forutsigbar, svakhet: to objekter som referer til hver andre vil aldri bli ryddet. (derfor har senere versjoner av CPython gjort ekstra tømming for også oppdage det), men selv nybegynnere skjønner dette veldig godt, ikke referer objekter til hver andre uten selv sjekke at de ryddes med del(obj). igjen problem solved.
