Eclipse OMR project provides a reusable Garbage Collector

[Chris Wright via Digitalmars-d]

On Sat, 03 Dec 2016 02:23:13 +0000, Dibyendu Majumdar wrote:
> IBM has open sourced the J9 Garbage Collector as part of Eclipse OMR
> project. Perhaps D could use this. It is claimed that the GC
> implementation is relatively straight forward to reuse.

That's awesome!

Unfortunately, it looks like incorporating it would take a fair bit of 
effort, and upstreaming it will not happen. I'm going to take a deeper 
look this weekend, but it's not looking good so far.

Druntime is under the Boost public license and will remain under it. OMR 
is dual licensed Apache2 / Eclipse Public License.

Druntime's GC system is pluggable, but the GC instance is set in a 
private variable in the `gc.proxy` module. You need to modify the runtime 
to add another GC implementation -- it's not something an application can 
just insert, and it's not something you can override just by linking in 
another library. (As far as I can determine. Corrections welcome.) And 
that makes the licensing problem much harder to work around.

That said, let's look at the API:

omrobjectptr_t OMR_GC_Allocate(OMR_VMThread * omrVMThread, uintptr_t 
allocationCategory, uintptr_t size, uintptr_t allocateFlags);

omrobjectptr_t OMR_GC_AllocateNoGC(OMR_VMThread * omrVMThread, uintptr_t 
allocationCategory, uintptr_t size, uintptr_t allocateFlagss);

omr_error_t OMR_GC_SystemCollect(OMR_VMThread* omrVMThread, uint32_t 
gcCode);

First parameter is a pointer to an OMR thread. I'd have to rewrite 
core.thread to use OMR's thread system, or maybe I could fake OMR threads 
with enough effort. That's another barrier.

The `allocationCategory` element is basically an object that describes 
the object model and lets OMR access type information. Looks like it 
expects us to be able to get the size of an object from a pointer to it. 
D's runtime *does* let you get this information for heap-allocated 
objects, but for arrays and heap-allocated structs, it does so by 
accessing the GC's internal data structures...yeah.

In D, you can malloc memory or memory map a file and put pointers in 
there. You manage this with the runtime by calling `GC.addRoot`. There 
doesn't appear to be an equivalent in OMR's GC. (Hard to tell, since it 
clocks in at 60KLOC.)

I *think* the AllocateNoGC function allocates but guarantees it won't 
collect memory. Not entirely certain. D's current runtime rather requires 
that.