[Alg] Vraag m.b.t. memory leaks

[bramseltje]

Tijdens een van de lessen op school hadden we een discussie met de leraar over memory leaks.

Hij zei dat memory leaks niet heel erg waren, omdat een programma van het OS een geheugen ruimte (pages) krijgt toegewezen, welke weer wordt vrijgegeven nadat het programma exit.

nu was ons idee dat het OS nooit kan weten of er niet meer naar dat geheugen verwezen wordt (de referencecount wordt nooit verlaagd ofzo) dus zal dat geheugen nooit worden vrijgegeven.

Nu vroeg ik me het volgende af:
Het is dacht ik zo dat sinds de NT-kernels er met pages gewerkt wordt, en een programma/proces krijgt een aantal van die pages toegewezen. Mocht je meer nodig hebben dan krijg je er wat pages bij.
Bij de oudere (9x) windows versie was dit nog niet zo, dus daar kreeg je gewoon een stukje geheugen, toch?

Maar als nu het OS bijhoudt welke pages er aan het programma toegekend zijn (Vandaar ook de "Page Access Faults" enzo als je aan iemand anders' ruimte komt), dan kan het OS toch ook in de gaten houden of het programma nog draait, en zo niet de pages weer vrijgeven voor gebruik?

Natuurlijk is het voor lang lopende processen dan nog steeds belangrijk dat je erop let dat je niet gebruikt geheugen vrijgeeft, omdat het anders langzaam aan vol loopt, maar voor een klein programmaatje, dat nooit meer dan de standaard ruimte (toegewezen pages) gebruikt zal het niet zo heel erg zijn toch?

Voor de duidelijkheid: Ik ben zelf ook niet overtuigd door m'n leraar, maar goed. Probeer zelf ook zonder leaks te programmeren (niet altijd even makkelijk ).

p.s. Iemand een idee hoe goed de memoryleak detectie van visual (c++) studio.NET en visual (c++) studio 6.0 is?

[PipoDeClown]

Bramseltje schreef op 31 mei 2004 @ 13:13:
Hij zei dat memory leaks niet heel erg waren, omdat een programma van het OS een geheugen ruimte (pages) krijgt toegewezen, welke weer wordt vrijgegeven nadat het programma exit.

nu was ons idee dat het OS nooit kan weten of er niet meer naar dat geheugen verwezen wordt (de referencecount wordt nooit verlaagd ofzo) dus zal dat geheugen nooit worden vrijgegeven.

indien je os zn boekhouding goed bijhoudt en garbage collecting doet is een lekkend progsel niet zo erg, maar dit gaat een keer fout.
[flame]sjeez wordt het nivo van de docenten met de jaren lager ofzo? of is het een omgeschoolde taxichaffeur[/flame]

[whoami]

Het geheugen dat jij niet vrijgegeven hebt, wordt zowiezo vrijgegeven als je applicatie afgesloten wordt.
Dat een memory leak niet zo erg is, moet je toch even nuanceren. Een memory leak kan wel erg zijn.

Garbage collecting wordt niet gedaan door het OS, maar door een virtual machine.

[Soultaker]

Je leraar heeft wel gelijk: het besturingssysteem kent resources toe aan een proces (niet alleen geheugen, maar ook mutexen, filehandles, netwerk sockets, enzovoorts) en die worden automatisch weer vrijgegeven al het proces beëindigd wordt. Je conclusie klopt dan ook wel: voor langlopende programma's (zeg: een HTTP server) is het van belang dat je geen geheugen lekt. Voor programma's die maar een beperkte uitvoerduur hebben is dat minder van belang, al kunnen memoryleaks er wel voor zorgen dat de maximale invoer die je kunt verwerken beperkt blijft (als je bijvoorbeeld per regel een stukje geheugen lekt).

Eigenlijk moet je in principe nooit geheugen lekken. Je kunt tegen die regel zondigen voor geheugen dat toch pas bij het einde van het programma vrijgegeven zou worden, zoals geheugen gealloceerd voor globale variabelen. En datastructuren die je tijdens het verwerken van invoer opbouwt.

Overigens heeft dit allemaal niets met garbage collection en references in het geheugen te maken. Het besturingssysteem alloceert resources en als het programma afsluit dan geeft die ze weer vrij, punt uit. Het besturingssysteem kijkt niet (en kan dat ook niet) naar wat er precies in dat geheugen stond. Het besturingssysteem is ook geen garbage collector!

Bramseltje schreef op 31 mei 2004 @ 13:13:
p.s. Iemand een idee hoe goed de memoryleak detectie van visual (c++) studio.NET en visual (c++) studio 6.0 is?

Ik denk dat Visual Studio al het gelekte geheugen vind dat je met de functies van de debug runtime library hebt gealloceerd. Lekken van shared memory of van geheugen gealloceerd bij andere processen (DLL's en dergelijke) zullen dan alleen gedetecteerd worden als ze ook de debug runtime library gebruiken.

PipoDeClown schreef op 31 mei 2004 @ 13:17:
indien je os zn boekhouding goed bijhoudt en garbage collecting doet is een lekkend progsel niet zo erg, maar dit gaat een keer fout.
[flame]sjeez wordt het nivo van de docenten met de jaren lager ofzo? of is het een omgeschoolde taxichaffeur[/flame]

Lekker nietszeggende uitspraak en op z'n minst nogal twijfelachtig gebruik van de term 'garbage collection'. Op basis van wat ik in deze thread heb gehoord heb ik meer vertrouwen in die omgeschoolde taxichauffeur van een docent dan in jou. [/FI]

[ Voor 33% gewijzigd door Soultaker op 31-05-2004 13:23 ]

[PipoDeClown]

whoami schreef op 31 mei 2004 @ 13:18:
Garbage collecting wordt niet gedaan door het OS, maar door een virtual machine.

ligt er maar aan hoe je virtual machine interpreteert

[whoami]

PipoDeClown schreef op 31 mei 2004 @ 13:20:
[...]

ligt er maar aan hoe je virtual machine interpreteert

Een virtual machine en een OS hebben imo niets met elkaar te maken. Een virtual machine is bv. de JVM of de CLR.

[bramseltje]

whoami schreef op 31 mei 2004 @ 13:18:
...
Dat een memory leak niet zo erg is, moet je toch even nuanceren. Een memory leak kan wel erg zijn.
...

je zult mij ook niet horen zeggen dat een memoryleak niet ernstig is. Nog even afgezien van mogelijke beveiligingsproblemen is het meestal toch een kwestie van slordig programmeren. En als je dat op memory gebied jezelf toestaat dan vaak ook op meer gebieden.

Soultaker schreef op 31 mei 2004 @ 13:19:
...

Eigenlijk moet je in principe nooit geheugen lekken. Je kunt tegen die regel zondigen voor geheugen dat toch pas bij het einde van het programma vrijgegeven zou worden, zoals geheugen gealloceerd voor globale variabelen. En datastructuren die je tijdens het verwerken van invoer opbouwt.

Het eerste ben ik met je eens. Maar het tweede, pas vrijgeven bij het einde v.h. programma, hoe kun je daar mee zondigen? Als je het eerder al vrijgeeft, dan kun je het toch niet meer gebruiken?

Soultaker schreef op 31 mei 2004 @ 13:19 ook nog:

Ik denk dat Visual Studio al het gelekte geheugen vind dat je met de functies van de debug runtime library hebt gealloceerd. Lekken van shared memory of van geheugen gealloceerd bij andere processen (DLL's en dergelijke) zullen dan alleen gedetecteerd worden als ze ook de debug runtime library gebruiken.

Hmm, dus als ik in een door mij opgestart process (thread?) wat met pointers goochel dan heeft VS dat niet door? Hmm... Maar ff goed opletten dan als we weer bezig gaan met ons project
_{p.s. wel lief blijven voor elkaar he...}

[Verwijderd]

Memory leaks zijn per definitie slecht!

Ik denk dat die leraar de term memory leaks een beetje verward met veel memory-gebruik, wat natuurlijk iets anders is:
- veel memory usage: tja, het programma heeft gewoon veel geheugen nodig, maar zal telkens maar zoveel aanvragen als dat het daadwerkelijk nodig heeft
- memory leaks: ongecontrolleerd opsoeperen van het beschikbaar geheugen, je ziet dat bvb in taskmanager, de memory usage blijft gestaag toenemen.

Ik denk dat de leraar het eerder had over overmatig memory gebruik, dan over memory leaks.

Merk bovendien ook op: garbage collection kan niks doen tegen memory leaks! Ja, op 't einde wel, maar zo lang het programma loopt, kan een programma dat last heeft van een memory leak wel zorgen dat het systeem crashed! (tenzij het OS nog andere voorzieningen getroffen heeft die hier specifiek op letten)

[Soultaker]

Bramseltje schreef op 31 mei 2004 @ 13:49:
Het eerste ben ik met je eens. Maar het tweede, pas vrijgeven bij het einde v.h. programma, hoe kun je daar mee zondigen? Als je het eerder al vrijgeeft, dan kun je het toch niet meer gebruiken?

Je interpreteert me verkeerd; ik zeg: de regel is dat je gealloceerd geheugen moet vrijgeven, maar tegen die regel mag je zondigen (dat wil zeggen: je mag nalaten om gealloceerd geheugen vrij te geven) voor geheugen dat toch pas aan het eind van het programma vrij zou komen. Ik geloof dus dat we het gewoon eens zijn.

Hmm, dus als ik in een door mij opgestart process (thread?) wat met pointers goochel dan heeft VS dat niet door? Hmm... Maar ff goed opletten dan als we weer bezig gaan met ons project

Visual Studio doet helemaal niets met pointers. Je mag daar mee goochelen wat je wilt. Als je geheugen alloceert uit de debug runtime library (in C bijvoorbeeld gewoon met malloc of in C++ met new of new[]) dan slaat 'ie dat in debug mode ergens op. Die informatie wordt weer verwijderd als er een corresponderende free/delete/delete[]/..whatever plaatsvindt. Aan het eind rapporteert Visual Studio welke stukken geheugen wel gealloceerd maar nooit vrijgegeven zijn, ongeacht wat jij ondertussen met pointers en dergelijke hebt gedaan.

Visual Studio zal dus al jouw memory leaks vinden (en los daarvan ook nog een heleboel andere geheugenfouten, trouwens) tenzij je je geheugen via andere methoden alloceert (direct bij Windows een page aanvragen, bijvoorbeeld; al zou ik niet eens weten hoe dat moet).

Verwijderd schreef op 31 mei 2004 @ 14:02:
Merk bovendien ook op: garbage collection kan niks doen tegen memory leaks! Ja, op 't einde wel, maar zo lang het programma loopt, kan een programma dat last heeft van een memory leak wel zorgen dat het systeem crashed! (tenzij het OS nog andere voorzieningen getroffen heeft die hier specifiek op letten)

Garbage collection heeft er niets mee te maken. Zullen we dat hier buiten beschouwing laten om ellende te voorkomen? Verder zou het wel heel erg jammer zijn als het besturingssysteem zou crashen als een programma te veel geheugen gaat gebruiken. In de praktijk wordt gewoon het proces dat buitensporig veel geheugen gebruikt beëindigd.

[ Voor 19% gewijzigd door Soultaker op 31-05-2004 14:17 ]

[Zoijar]

Die leraar heeft wel gelijk op een bepaalde manier, alleen legt hij het niet zo handig/duidelijk uit (of luisteren jullie niet goed ). Een process weet welk geheugen het heeft gealloceerd, en als het process eindigt dan zal dit worden vrij gegeven. Stel dat je nu bv een singleton object hebt dat is gealloceerd op de heap, dan hoef je dat niet vrij te geven aan het eind van je programma; puur vanuit memory leak oogpunt. Dat is dan ook feitelijk geen (resource) leak.

Dit neemt niet weg dat je vaak toch wel het object had willen destructen, bv om caches te flushen, connecties graceful te closen, etc. Dus dan wijst een 'leak' van dit soort vaak toch op een fout. Maar het hoeft dus niet per se.

Garbage collection is iets wat het runtime system doet. Je kijkt op bepaalde tijden of je draaiende programma nog mogelijkheden heeft om bij stukken geheugen te komen. En als dat niet zo is kan je ze vrij geven.

[Verwijderd]

Ik snap niet hoe die leraar erbij komt dat memory-leak niet slecht zou zijn. De redenering is: aan het eind wordt het toch weer recht gebreid.
Een programma moet simpelweg zo min mogelijk geheugen gebruiken en geheugen direct vrijgeven als het niet meer nodig is. Of het nou gaat om een programma dat maar een half uurtje hoeft te draaien of een programma dat 24/7 draait; 't maakt niets uit.
Wanneer een programma onnodig veel geheugen gebruikt (niet vrijgeeft nadat het niet meer nodig is etc.), dan kunnen andere programma's niet meer draaien.
Vroeger was men dol gelukkig met 4kb geheugen, tegenwoordig maakt het niets meer uit: we hebben toch genoeg geheugen.
Dat is gewoon een stomme redenering. Een programma moet zo compact en snel mogelijk zijn.
In het boek "The Art of Assambly" staat: "It is amazing that people will spend lots of money to buy a machine slightly faster than the one they own, but they won't spend any extra time writing their code in assembly so it runs faster on the same hardware."
Nu gaat het in dat citaat om snelheid, maar hetzelfde geldt voor geheugen.

[RayNbow]

Verwijderd schreef op 31 mei 2004 @ 16:12:
In het boek "The Art of Assambly" staat: "It is amazing that people will spend lots of money to buy a machine slightly faster than the one they own, but they won't spend any extra time writing their code in assembly so it runs faster on the same hardware."
Nu gaat het in dat citaat om snelheid, maar hetzelfde geldt voor geheugen.

Hoge snelheid en weinig geheugengebruik gaan echter niet altijd samen, dus soms moet je een keuze maken.

[curry684]

Verwijderd schreef op 31 mei 2004 @ 16:12:
In het boek "The Art of Assambly" staat: "It is amazing that people will spend lots of money to buy a machine slightly faster than the one they own, but they won't spend any extra time writing their code in assembly so it runs faster on the same hardware."

Wat een idioot stomme opmerking indien gemaakt na ~1995. Een programma als Outlook schrijven in C/C++ kost met ~50 man 2 jaar. In assembly minimaal een factor 5-10 meer, wat het produkt meer dan evenredig duurder maakt (assembly experts zijn zeldzamer en dus duurder dan C++'ers) en bovendien vrijwel unmaintainable voor iemand die niet origineel eraan meegewerkt heeft. Dus wat heb je dan voor je 10 keer duurdere produkt: een hoogstwaarschijnlijk langzamer programma omdat je compiler wel blind alle slimme optimalisaties met cache bounds, bus conflicts, branch prediction en alles uit kan halen die jij in je blote hoofd onmogelijk kunt behappen. Tenzij op kleine geisoleerde schaal toegepast outperformed C/C++ native-written assembly vrijwel altijd. Echt een enorm slechte vergelijking dus.

Wat memory leaks betreft: ruim altijd al je troep op achter je kont. Je gaat spijt hebben als je in een proggie een leak toestaat dat je vervolgens 2 jaar later zonder nadenken gaat ombouwen om 50000 keer in batch te draaien. Vind dan die 'bewust vergeten' leak nog maar eens terug. Alle leaks zijn evil, punt.

[ Voor 4% gewijzigd door curry684 op 31-05-2004 16:39 ]

[bramseltje]

Verwijderd schreef op 31 mei 2004 @ 16:12:
Ik snap niet hoe die leraar erbij komt dat memory-leak niet slecht zou zijn. De redenering is: aan het eind wordt het toch weer recht gebreid.
Een programma moet simpelweg zo min mogelijk geheugen gebruiken en geheugen direct vrijgeven als het niet meer nodig is. Of het nou gaat om een programma dat maar een half uurtje hoeft te draaien of een programma dat 24/7 draait; 't maakt niets uit.
Wanneer een programma onnodig veel geheugen gebruikt (niet vrijgeeft nadat het niet meer nodig is etc.), dan kunnen andere programma's niet meer draaien.
Vroeger was men dol gelukkig met 4kb geheugen, tegenwoordig maakt het niets meer uit: we hebben toch genoeg geheugen.
Dat is gewoon een stomme redenering. Een programma moet zo compact en snel mogelijk zijn.
In het boek "The Art of Assambly" staat: "It is amazing that people will spend lots of money to buy a machine slightly faster than the one they own, but they won't spend any extra time writing their code in assembly so it runs faster on the same hardware."
Nu gaat het in dat citaat om snelheid, maar hetzelfde geldt voor geheugen.

Mijn bedoeling was ook niet om te discussieren over het feit of memoryleaks erg zijn of niet, maar het ging om de vraag of ze nu wel of niet door het OS worden opgeruimd (of door de VM/CLR). Die leraar heeft ook geen waarde oordeel gegeven, alleen melding gemaakt van het feit dat (normaal gesproken) de geheugen ruimte en andere toegewezen resources van het programma toch compleet weer vrijgegeven worden.

Okee, ik geef toe, het was misschien wat onduidelijk, maar ik ben het met je eens. Zeker voor wat grotere programma's of echt commerciele programma's is het absoluut niet netjes om memoryleaks te laten zitten.

Gelukkig hoef ik op school geen commerciele programma's te schrijven...
(Al is het wel de bedoeling dat het resultaat van ons project door de 1e jaars wel gebruikt gaat worden. Vandaar ook een beetje mijn vraag)

curry684 schreef op 31 mei 2004 @ 16:37:
[...]


Wat memory leaks betreft: ruim altijd al je troep op achter je kont. Je gaat spijt hebben als je in een proggie een leak toestaat dat je vervolgens 2 jaar later zonder nadenken gaat ombouwen om 50000 keer in batch te draaien. Vind dan die 'bewust vergeten' leak nog maar eens terug. Alle leaks zijn evil, punt.

Dat heb ik hierboven toch ook al zo'n beetje duidelijk proberen te maken? Ik ben het wat dat betreft best met je eens hoor...

Vind je niet lief, als je zo lelijk tegen me doet...

[ Voor 23% gewijzigd door bramseltje op 31-05-2004 16:42 ]

[curry684]

Bramseltje schreef op 31 mei 2004 @ 16:38:
[...]

Zeker voor wat grotere programma's of echt commerciele programma's is het absoluut niet netjes om memoryleaks te laten zitten.

Maak er 'zeker bij ieder programma' van en ik wil erover twijfelen om je in dienst te nemen De juiste instelling is belangrijk: sta je jezelf toe te slacken in 'mini-hobby-projectjes' dan ga je vanzelf ook slacken in commerciele of grote programma's. Gemak werkt verslavend helaas

Vind je niet lief, als je zo lelijk tegen me doet...

Wie doet lelijk tegen je? Ik maak enkel het punt wat sterker en gedecideerder omdat ik vond dat het nog niet helder genoeg als onbreekbare regel was gesteld

[Robtimus]

Ik ben het volledig met oa curry eens: memory leaks zijn evil.

Als je niet in staat / bereid bent fatsoenlijk aan geheugenbeheer te doen, dan moet je maar een taal met GC gebruiken zoals Java of Python.

Zelf gebruik ik valgrind op al mijn Linux programma's; pas wanneer die zegt dat mijn code geen fouten bevat (memleaks, etc) vind ik het goed en niet eerder.

[bramseltje]

curry684 schreef op 31 mei 2004 @ 16:46:
[...]

Maak er 'zeker bij ieder programma' van en ik wil erover twijfelen om je in dienst te nemen De juiste instelling is belangrijk: sta je jezelf toe te slacken in 'mini-hobby-projectjes' dan ga je vanzelf ook slacken in commerciele of grote programma's. Gemak werkt verslavend helaas

Voor mezelf was ik er al van overtuigd dat het absoluut niet netjes is wanneer dan ook...

Ik schreef zelf op 31 mei 2004 @ 13:49:
[...]
je zult mij ook niet horen zeggen dat een memoryleak niet ernstig is. Nog even afgezien van mogelijke beveiligingsproblemen is het meestal toch een kwestie van slordig programmeren. En als je dat op memory gebied jezelf toestaat dan vaak ook op meer gebieden.

Ga je er nu over denken me in dienst te nemen?

Weet trouwens niet of je iets aan me hebt, officieel doe ik Electro techniek. Kan wel handig zijn als je iets met hardware/communicatie enzo doet, maar voor 100% software? Hmm, ben ik niet echt geschikt voor

edit:
/ vergeten

[ Voor 3% gewijzigd door bramseltje op 31-05-2004 17:20 ]

[MBV]

Ik wil er nog iets aan toevoegen (ik hoop dat de rest dan stopt met herhalen ): Ook al maak je een programma dat nu dedicated 1 ding doet van 20 min, en daana afsluit. Dan bestaat de kans dat je programma toch uiteindelijk wordt verbouwd tot server, en 2 jaar lang 24/7 aan gaat staan. Veel programma's zijn daarop de mist in gegaan (y2k, anyone? )

En als laatst nog een stelregel, waar memory leaks ook op neerkomen:
Always write your code as if the one who's going to maintain it is a violent psychopath who knows where you live.

[whoami]

IceManX schreef op 31 mei 2004 @ 17:06:

Als je niet in staat / bereid bent fatsoenlijk aan geheugenbeheer te doen, dan moet je maar een taal met GC gebruiken zoals Java of Python.

Hah, ook in een 'managed' taal kunnen er memory leaks in je code sluipen.

Stel dat je in een managed taal bv. een stack class maakt. Die class gebruikt een ArrayList waarop je items pushed, en vanwaar je popped.

Stel dat die class er zo uit ziet:

code:

class MyStack
{
    private ArrayList   aList;
    private int            aPtr;

    public MyStack()
    {
        aList = new ArrayList ();
        aPtr = -1;
    }

    public void Push( object anObject )
    {
        aPtr++;
        aList.Insert (aPtr, anObject);
    }

    public object Pop()
    {
        return aList[aPtr--];
    }
}

In deze code zit een memory leak.
In de Pop verlaag je nl. de pointer naar waar het volgende element verwijst, maar het element zelf geef je niet vrij.
_{Nog afgezien van het feit dat bovenstaande code niet echt de beste code is, ipv Insert te gebruiken gebruik je beter Add, en ipv een pointer bij te houden kan je de property v/d arraylist gebruiken die aangeeft hoeveel elementen erin zitten, en bij de Pop remove je iedere keer het laatste item}

[Cuball]

van zodra er geen referentie meer is naar het object van type MyStack dan zorgt de GC ervoor dat die mooi vrijgegeven wordt... kan je niet vergelijken met een memory leak zoals in C/C++ imo

[MSalters]

MBV schreef op 31 mei 2004 @ 17:25:
Ik wil er nog iets aan toevoegen (ik hoop dat de rest dan stopt met herhalen ): Ook al maak je een programma dat nu dedicated 1 ding doet van 20 min, en daana afsluit. Dan bestaat de kans dat je programma toch uiteindelijk wordt verbouwd tot server, en 2 jaar lang 24/7 aan gaat staan. Veel programma's zijn daarop de mist in gegaan (y2k, anyone? )

Een willekeurige run once&exit tool ombouwen tot 24/7 server is tenminste net zo dom als een memory leak. De problemen die je schetst kun je dus niet echt aan een partij verwijten.

Ik heb een keer een memory leak verholpen, terwijl dat achteraf onodig was. Ook dat was een tooltje was een keer runde. De deallocatie daar duurde 90%van de runtime. Poging 1: memory leak introduceren, 10 keer zo snel. Poging 2, dedicated memory manager geschreven. 10% langzamer oid dan poging 1, oftewel boeit niet, alleen de 10 dagen werk hebben in de twee jaar daarna geen rendement opgeleverd.

[.oisyn]

Ik ga even alleen in op de dingen die nog niet naar voren zijn gekomen

Bramseltje schreef op 31 mei 2004 @ 13:13:
Hij zei dat memory leaks niet heel erg waren, omdat een programma van het OS een geheugen ruimte (pages) krijgt toegewezen, welke weer wordt vrijgegeven nadat het programma exit.

Dat klopt

nu was ons idee dat het OS nooit kan weten of er niet meer naar dat geheugen verwezen wordt (de referencecount wordt nooit verlaagd ofzo) dus zal dat geheugen nooit worden vrijgegeven.

Dat klopt niet helemaal. Een OS kent idd pages toe, en zorgt op die manier voor een grotere werkruimte dan de totale hoeveelheid geheugen die je hebt. Het OS zal proberen zoveel mogelijk gebruikte pages in het geheugen te houden, maar op een gegeven moment is het geheugen vol en zal het OS ze naar disk schrijven, alvorens hij een andere laadt (dit heet swapping). Als een applicatie wil schrijven naar een page die op dat moment niet in het werkgeheugen is geladen, dan treedt er een exception op (page fault), en dan inspecteert de kernel waardoor die pagefault is opgetreden. Vervolgens laadt hij de betreffende page in (en schrijft ie mogelijk een andere weg om ruimte te maken), en wordt de instructie van het proces dat die page fault heeft veroorzaakt opnieuw uitgevoerd. Dus grote memory leaks in een runnende applicatie zorgen voor veel geswap en grotere pagefiles (voor zover dat mogelijk is). Een korte applicatie die lekt is zoals al genoemd niet echt erg, omdat het geheugen (en andere geclaimde resources) sowieso wordt vrijgegeven als de applicatie wordt afgesloten.

Nu vroeg ik me het volgende af:
Het is dacht ik zo dat sinds de NT-kernels er met pages gewerkt wordt, en een programma/proces krijgt een aantal van die pages toegewezen. Mocht je meer nodig hebben dan krijg je er wat pages bij.
Bij de oudere (9x) windows versie was dit nog niet zo, dus daar kreeg je gewoon een stukje geheugen, toch?

Win9x gebruiit ook paging hoor. Een OS zonder paging is vrij onwerkbaar, omdat je dan gewoonweg niet goed aan memory management kunt doen

p.s. Iemand een idee hoe goed de memoryleak detectie van visual (c++) studio.NET en visual (c++) studio 6.0 is?

Zie de functies _CrtSetDbgFlag () en _CrtCheckMemory (), en nog wat aanverwanten zoals _CrtSetBreakAlloc ().

Er zijn ook externe tools die memory leaks kunnen reporten alsmede het exacte moment waarop ze gealloceerd zijn. Rational Purify is bijvoorbeeld een heel erg mooi (en duur ) tooltje

[whoami]

Cuball schreef op 01 juni 2004 @ 00:07:
van zodra er geen referentie meer is naar het object van type MyStack dan zorgt de GC ervoor dat die mooi vrijgegeven wordt... kan je niet vergelijken met een memory leak zoals in C/C++ imo

Ik heb het niet over het object MyStack zelf, maar over de objecten die op MyStack gepushed worden.

[Robtimus]

whoami schreef op 01 juni 2004 @ 08:27:
[...]


Ik heb het niet over het object MyStack zelf, maar over de objecten die op MyStack gepushed worden.

Je vergeet iets: zodra je een ander object pusht overschrijf je de reference, dus kan het alsnog geGC'ed worden. Als je echter eerst veel pusht en daarna alleen maar popt, heb je idd een gigantisch lek.

Dus je hebt gelijk: zelfs in talen met GC kun je slechte code schrijven. Je hoort nml natuurlijk de laatste reference te overschrijven met een null oid.

[Soultaker]

Overigens neemt die stack van whoami niet meer geheugen in gebruik dan de maximale hoogte ervan (of een beperkt percentage meer; dat hangt een beetje van de implementatie van ArrayList af). Ik kan me daardoor voorstellen dat zelfs als het object lang blijft leven er weinig problemen bij het gebruik optreden. Als je er bijvoorbeeld de declaration scopes in een compiler mee bijhoudt (om maar wat te noemen) dan zal 'ie nooit meer dan enkele tientallen entries alloceren, ook al doe je er miljoenen push en pop operaties op.

Sterker nog, deze stack heeft de eigenschap dat 'ie z'n interne buffer automatisch aanpast aan de te verwachten vereiste grootte. In bepaalde situaties kan ik me voorstellen dat dit juist een performance voordeel oplevert; push en pop operaties zijn een stuk sneller als er niet bij gealloceerd of gedealloceerd hoeft te worden. Een stack die z'n geheugen elke keer weer zou inkrimpen zou bij miljoenen push en pop operaties misschien ook wel miljoenen allocaties en deallocaties doen (al dempt het allocatieschema van de ArrayList het aantal wel, juist door ook te veel ruimte te alloceren).

Al met al zal door deze 'memory leak' het maximale geheugengebruik waarschijnlijk niet hoger zijn dan het maximale geheugengebruik met een 'veilige' stack (al kun je wel situaties construeren waarin dat wel het geval is). Het valt dus nogal mee met dat lek. Natuurlijk moet je er wel voor zorgen dat als je zulke constructies gebruikt, je op de hoogte bent van de eigenschappen ervan (en die ook in de praktijk getest hebt!); het is natuurlijk niet de bedoeling dat je eerst slechte code schrijft en daarna situaties gaat bedenken waarin die code goed tot z'n recht komt.

[whoami]

Een arraylist heeft een capacity.
Die capacity kan je meegeven met de constructor, en als je dat niet doet, is de default capacity 25 objecten dacht ik.

Als je een item toevoegt, en de capaciteit wordt overschreden, dan wordt er geheugen gealloceerd; de capacity wordt dan verdubbeld.

Een ArrayList gaat niet automatisch 'shrinken'. Dat moet je als programmeur zelf doen als je dat wilt door de Capacity property aan te passen, of door TrimToSize oid aan te roepen.

/offtopic.