large objects and GC

Fawzi Mohamed fmohamed at mac.com
Sat May 17 14:49:22 PDT 2008


On 2008-05-17 21:35:07 +0200, Sean Kelly <sean at invisibleduck.org> said:

> == Quote from Fawzi Mohamed (fmohamed at mac.com)'s article
>> On 2008-05-17 10:42:21 +0200, "Vladimir Panteleev"
>> <thecybershadow at gmail.com> said:
>>> On Sat, 17 May 2008 10:54:06 +0300, Fawzi Mohamed <fmohamed at mac.com> wrote:
>>> 
>>>> Now the pool will stay around as long as any objet into it has references.
>>> 
>>> Heh, no, this is not the case. The GC will track references
>>> individually for every object inside the memory pool. The code for
>>> freeing sub-pool-size objects is in gcx.d, lines 2056 to 2075.
>> Thanks if that is the case then wrapper objects are ok.
>> gcx.d, lines 2056 to 2075 of which codebase, where can I get that gcx?
>> tango varsion has something else at those lines...
> 
> In Tango:
> 
> /trunk/lib/gc/basic/gcx.d
> 
> In Phobos:
> 
> /internal/gc/gcx.d
> 
> For what you describe, the easiest thing would be to add a new bitfield
> and have an "allow interior pointers" per block, then check this bit during
> scanning before flagging a block as reachable.
> 
> 
> Sean

thank you for the explanation, I had badly interpreted the "gc does not 
know anything about the objects", and I didn't actually try to test my 
understanding with a program.
For what I want to do a wrapper object that does manual memory 
allocation fits the bill nicely.

My proposal could still be useful to transform a-posteriori a large 
existing object to this memory management mode, and could avoid the 
need to have to manually delete it (as for example requested in 
http://d.puremagic.com/issues/show_bug.cgi?id=2105 ).

I will look into the possibility of introducing this in the gc and 
having a function that given a pointer chacks if it has a full pool for 
only an object (and no space left for other objects) it switches the 
flag "no internal pointers".
But as I don't need it, don't expect anything :)

Fawzi




More information about the Digitalmars-d mailing list