🚀 go-pugleaf

In article <a5dvl8$6h8eb$1@ID-65051.news.dfncis.de>, Armin Gerritsen wrote:
> "Johan Wevers" <johanw@iae.nl> wrote in message
> news:3C7A5882.3B898C88@iae.nl...
> 
>> > Mijn vraag is dus eigenlijk waarom faalt een new-operator? Documentatie
> zegt
>> > bijvoorbeeld als er niet genoeg geheugen vrij is. Maar 300MB lijkt me
> toch
>> > genoeg voor 14kB? :-)
>>
>> > Iemand enig idee?
> 
>> Heap fragmentation? Alloceer eens een geheugenblok van 15kb in het begin,
> en
>> geef dat vrij net voordat je de new die crasht uitvoert. Als het dan goed
> gaat
>> heb je kans dat dat het probleem is.
> 
> Inderdaad!
> Dat is het probleem. Bedankt.
> 
> Nu nog de vraag hoe ik het op moet lossen.
> 
> - Ik kan mijn programma omschrijven dat ik aan het begin 'worst-case'
> allocaties doe en die buffers herbruik. Nadeel is echter wel dat ik niet met
> 100% zekerheid kan zeggen wat 'worst-case' is (maar wel wat het nooit zal
> zijn) en dus onnodig groot moet zitten in mijn algorithmes. Ook is er een
> verschil tussen 'worst-case' en gangbaar. M.a.w. mijn app gaat flink
> geheugen verspillen. Is een optie als niets anders kan, maar liever een
> andere proberen. :-)

Je kan de pijn daarvan wat verzachten door meerdere lijsten met grootte categorien te maken.

Dus niet een list met ongebruikte blocks, maar meerdere, voor meerdere ranges. 
 
> - heap 'defragmenteren'. Zo ja hoe?

Niet mogelijk bij gecompileerde talen.

> - heap vergroten? Zo ja hoe?

Zou automatisch moeten gaan, met een initiele waarde (om startup vertraging
te voorkomen) Zie de diverse menutjes.

> - Iets anders?

Andere heapmgr.

Zit je in een debug mode? Dan zou het kunnen zijn dat de echte app het probleem niet/minder heeft. Debug
modes gebruiken wel eens speciale heapmgrs om bepaalde dingen (memleaks, corruption) te kunnen tracen.