RE: Re: A non-sucking garbage collector

Christian Tismer wrote:

>> Of course there is a overhead of memory (up to a factor of 
>two) due to 
>> the fact that you need the old arena and the new at the same time.  
>> This is reduced if you have multiple generation arenas and the old 
>> isn't copied.  So adding the generational enhancement improves both 
>> speed and memory requirements.
>
>I agree this is a simple and efficient scheme to do garbage 
>collection, at the price that you have _all_ object references 
>one level of indirecton away, every pointer from object to 
>object must go through the global object table, and you 
>probably _never_ can rely on any direct reference, if a 
>garbage collection can happen in between. 

Not true.  Once you read-lock an object, you can use the direct pointer
in a register as much as you wish, even when the garbage collector is
running. This is because the memory manager is fully integrated with the
locking mechanism and will not free up a memory arena until all the
objects in an arena release every lock in the arena.  Once again the
locking objects save the day.

>I have no clue how 
>big the cost is. Maybe it is even more efficient than the 
>Python combination of refcounting/generational gc. If you can 
>make sure that gc can happen only at certain times, you can 
>keep references in registers long enough. 

The GC can run (do a flip) at any time, but the old memory arena will
stay around keeping the old object data valid and the register pointers
valid.  Since the object is read-locked, it doesn't matter if the data
is old because it cannot change anyway.  

The only disadvantage of keeping an object read-locked too long is that
it will keep old memory from being reclaimed.  The memory manager can
complain if an arena is kept around too long by issuing a time-out
error.  Obviously code should keep things locked for as short a time as
possible but this is always a desirable goal for many reasons.

>What stays is the 
>double indirection all over the place. Do you think it is easy 
>to undo this change if it turns out to be inefficient?

It turned out to be only a few hours for me to split the objects into
two parts for this scheme. One part is the non-copying tiny (8 bytes)
part that stays in the global table and the rest is the data part that
gets copied.  So I am not concerned about how hard it would be to switch
back. 

I was quite surprised when the interpreter ran first try after the
switchover. :-)  Writing the new garbage collector from scratch is
turning out to be harder.