Eclipse OMR project provides a reusable Garbage Collector

[Chris Wright via Digitalmars-d]

On Sat, 03 Dec 2016 15:45:00 +0000, Chris Wright wrote:
> Also, OMR assumes there are no unaligned pointers to GC memory.

Also no pointers-to-members, but I have a way around both these problems. 
Obvious in hindsight.

The memory overhead is O(#allocations). The time overhead is O(lg 
#allocations) per pointer reference per scan.

So we won't see numbers as impressive as Java's, unfortunately -- not 
unless we forbid pointers-to-members and rework array slicing.


The details:

When I allocate a thing, I insert an entry for the thing into an ordered 
set of allocated ranges. The entry will be a (begin, end) pointer pair 
for the allocation. I can get this info because allocations tell me how 
much to allocate, and OMR's GC gives me a pointer.

When inserting that allocated range into the set, I will have to erase 
any overlapping elements. This shouldn't be difficult -- as long as the 
no-overlapping-ranges invariant was maintained before this call, I only 
have to look one element to the left, and it's quick to determine how far 
to the right I need to look.

When scanning an object, we find the pointers in that object as we 
currently do. Then, instead of enqueueing those pointers to be scanned, 
we look them up in the allocation set and enqueue the allocation's 
`begin` pointer.

Pretty much what we do today. It's just replacing a little less of the GC 
than we would prefer.