[RFC]Proposal for better garbage collection

deadalnix deadalnix at gmail.com
Thu Feb 23 09:01:48 PST 2012


Le 22/02/2012 20:53, Benjamin Thaut a écrit :
>
> If you have a better idea for percise stack scanning I'm open for
> suggestions.
>


This is the problem with your proposal. It doesn't consider pro and cons 
and actual data. It doesn't consider the alternatives. You go straight 
to « How can we do that ? » without condidering « should we do that ? »

What would be the impact of being precise on the heap but not on the stack ?

1/ It would add some false positives. The future being 64bits, False 
positive will be way less present than on 32bits machines. I did 
searched for numbers on that, but couldn't found them. Considering this 
is only on the stack, this may be neglectible (or not, but it 
definitively require data).

2/ Data pointed by the stack are not movable.Again, what is the impact 
of that. How much data could be promoted from young generation to old 
one (considering we have young and old gen). How much data couldn't be 
compacted ? What would the overhead on allocators ?

This definitively lack the required data and/or analysis of pro and cons.

Additionnaly, the stack is made like a linked list. Each function 
calling another one register the return address. With this information, 
we can have data about what is on the stack except for the very last 
function called with no runtime overhead. This is another alternative.

But you have to consider that, even with a mask, you are not sure that 
what is marked as a pointer is a pointer. A memory location can 
represent different thing during a function execution. So thoses values 
can only be considered as probable pointers, or we disable some compiler 
optimizations. As we cannot be sure, the point 2/ stay valid.

Granted the overhead of the operation, it ay not worth it. To know that, 
we need actual data on how much data is the stack is actually pointer, 
and how much false positive we get. As the future is 64bits, I'm not 
sure it is interesting for us.


More information about the Digitalmars-d mailing list