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.