Skip to main content.


This is the archive for March 2009

Monday, March 30, 2009

A few verses of an Italian free spirit:

Gl'abusi un altro a criticar s'accinga,
per me da questa pasta alzo le mani:
canti ognun ciò che vuol, scriva o dipinga,
ch'io non vo' dirizar le gambe a i cani.

Let someone else to criticize the rants,
as for me, from this stuff I lift my hand right:
everyone sing, write or paint what he wants
as I don't go around turning dog legs straight


Salvator Rosa -- Tirreno

Sunday, March 01, 2009

One of the things the GC has to know about its memory, is "generically" how much memory has been allocated.

Usually, you will want to know how much memory you may expect to reclaim before start a GC loop. If the game is not worth the candle, then just wait for a better time.

The previous Falcon GC was greedingly asking to every involved element of the process to accurately account its usage of GC sensible memory. It was an enormous waste of resources, but it was necessary, at the time, to make our poor under-engineerized GC to work correctly and punch in only at suitable times.

In 0.9, I am having a global variable called "allocatedMem" to account memory allocation through the global allocation function pointer we're using for that task. In the first phase of 0.9 development I am recording memory from every allocation, through the "BaseAlloc" class which overloads new/delete and points to memAlloc. But a GCAlloc class is ready and will be applied to those BaseAlloc derived items that may end up in the stack or will do for sure (i.e. strings and core objects). This means that we're accounting everything now, while we'll be more relaxed later on as 0.9 gets more solid.

Actually, sensible objects are already derived from GCAlloc, while other objects are derived from BaseAlloc; just, memAlloc functions (used by BaseAlloc class new/delete) are pointing to the same low level functions of GCAlloc. During 0.9 devel we may remove BaseAlloc completely, or return memAlloc to point just to malloc().