Eclipse OMR project provides a reusable Garbage Collector

[Chris Wright via Digitalmars-d]

On Sat, 03 Dec 2016 10:29:02 +0000, Dibyendu Majumdar wrote:
> I would imagine that some effort is necessary ... but the payoff is huge
> isn't it ? To have a robust GC would change the game for D.

It's possible that ldc and gdc will switch their runtimes to use OMR, but 
dmd will not.

I might be able to provide an alternate runtime with dub. Will have to 
investigate. If that works, we might end up splitting the runtime in two 
-- a lot of the runtime won't need to change, and I'd rather not have the 
maintenance overhead for typeinfo and unicode handling just to provide a 
better GC.

> I think all GCs need to interact with threads so there has to be some
> linkage between the thread sub-system and GC.

True. If this project were designed to be used a la carte, it would have 
a pluggable mechanism for identifying thread stacks and pausing threads. 
That would make it much easier to port a runtime to OMR, but it would 
make OMR more complex -- and it's already 775kLOC.

It adds more work to my plate, but I can deal.

> I saw a slide deck or some docs that explained the requirements to use
> OMR GC. Unfortunately I did not save a link and cannot locate this now.
> I will post a link if I find it again.

Thanks! Watching it now.

> It said that the OMR expects objects to be allocated on 8-byte aligned
> memory and it requires one GC byte - which is assumed to be at the start
> of the allocated object but can be changed if required.

One byte for the GC, or one byte of overhead for the glue layer to use?

Assuming that all structs are padded to word boundaries, one byte would 
allow a 256-word struct. I can create a struct with 10,000 fields, and 
each can be more than one word.