🚀 go-pugleaf

In article <3f6c3fca$0$59340$e4fe514c@dreader8.news.xs4all.nl>, Ramon Smits wrote:
> Marco van de Voort wrote:
> 
>>>Dat zeg ik ook niet :). It's all about design. Waarom een object continu 
>>>creeeren en destroyen als je weet dat je die actie per uur 1 miljoen 
>>>maal moet doen. Dan is het nuttig dergelijke objecten te cachen. Maar 
>>>dat is eigenlijk altijd al geweest.
>> 
>> Als ze in een freelist zitten voor een bepaalde grootte, zijn ze al
>> gecollect. Dus gecachete allocaties tellen niet mee in je applicatie
>> geheugen gebruik. (tenzij je VM/heapmanager ze niet freed als de memory
>> low watermark gehaald wordt )
> 
> Wat is een freelist? Een lijst van alle recources waar geen references 
> vanuit de applicatie meer staan?

Een lijst met gedealloceerde (GC of handmatig) geheugen bereiken. Meestal
van een bepaalde grootte categorie. Soms zijn ze meervoudig gesorteerd. (op
grote en op volgorde, sorteren op volgorde maakt mergen van aansluitende
blokken makkelijker) 

Dit om compacting en merging makkelijker te maken. De freelist zijn dus
gecachte stukjes geheugen, geen echte objecten meer. (al kan dat als
optimalisatie evt in sommige talen toegevoegd worden)

> Inderdaad... de tresshold bepaald wanneer de garbage collector gaan 
> handelen. Maar dan moet inderdaad wel die tresshold behaald worden 
> tijdens het draaien van de betreffende applicatie.
 
Mijn punt was dat geheugen dat nog niet geGCed is, niet hergebruikt wordt.
Ik reageerde op die opmerking over "geheugen cachen", maar ik zie nu dat
jij dat misschien "handmatig' (zelf) cachen heb bedoeld, terwijl ik
caching in the memorymanager van de taal bedoelde.

>> Maar de vertraging die uitswappen kost tijdens gewoon werken (en b.v. eens
>> in de 10/20 minuten switches) is IMHO ook al fout, dat werkt al niet lekker
>> meer als ie dan 10 seconden gaat trashen, om even iets in de documentatie
>> te cut and pasten.
> 
> Inderdaad.. dat is ook vrij irritant. Garbage collecten wil je ook op 
> die momenten doen zodra de betreffende applicatie idle is. Dat doet de 
> VM in Java en .NET maar een C++ applicatie heeft dergelijke 
> functionaliteit vaak niet omdat het een hels karwij is.

Ik weet dat het onder delphi vermoedelijk wel kan, en van  C++ ben ik ook
redelijk zeker.
Al valt dat dan onder de non-cooperative languages. waar je dus in de GC
geen gealloceert geheugen kan laten verplaatsen, hetgeen tot fragmentatie.
Maar mark en sweep zijn universeel, en een thread en event driven applicaties
bestaan in die beide talen ook.

> De gebruiker merkt vaak deze opschoon acties dan ook vaak helemaal niet in
> Java en .NET. Het enige wat de gebruiker merkt is het jit compileren van
> de code.

Ik weet dat niet. Er waren vroeger veel problemen mee, maar ik weet niet
of deze opgelost zijn door nieuwere, betere VMs, of door zwaardere machines
met meer geheugen (en dat dan ook relatief tot de last).
 
> Maar zolang systeem geheugen nog riant beschikbaar is is garbage 
> collecten nog helemaal niet nodig. Dat is wat ik duidelijk probeer te 
> maken. De .NET VM zal dat dan ook niet snel doen.
> 
>> De applicaties die genoemd werden zijn allemaal interactief. Voor slapende
>> services kan ik het me nog voorstellen.
> 
> Wat kun je je voorstellen? Dat die idle zijn? Interactieve applicatie 
> zijn ook net zo vaak idle.

Dat uitswappen niet problematisch is. Voor een applicatie die weinig
gebruikt wordt, maar toch regelmatig (iedere zoveel minuten b.v.) kan
het erg irritant zijn.