Does Alloy use boehmgc for all allocations?

[MarcWeber]

Location

The Readme says cannot trace pointers unless using global allocators ?
So does it use boehmgc for all allocations ?
Wouldn't a better solution be a using a different allocator which when claiming memory from system registers than at boehmgc ?
So what's the benefit of using boehmgc for all allocations ? Wouldn't boehmgc be faster if it had to trace only pointers to GC<..> pointers ?

Summary

So it would be nice if you could document your intuition about this.

[jacob-hughes]

Hello Marc,

Wouldn't a better solution be a using a different allocator which when claiming memory from system registers than at boehmgc ?

In Alloy, we want to allow pointers to Gc<T> objects from non-GC'd heap allocations (i.e. Box<T>). The collector must therefore assume that any heap-allocated block could contain a pointer. Using the boehmgc's allocator for these non-GC'd allocations ensures that the collector will trace these blocks for indirect GC objects (i.e. GC objects not directly reachable from the stack).

Wouldn't boehmgc be faster if it had to trace only pointers to GC<..> pointers ?

Yes it would, but then we wouldn't be able to mix GC and non-GC'd objects.

Additionally, Alloy is fully conservative so a potential future improvement could be to use type information to allocate objects without boehmgc-alloc where we can guarantee that their memory never points to a Gc<T>.

[MarcWeber]

Or the allocator when getting memory from system must register/unregister the blocks at boehmgc to be scanned.

[ltratt]

@MarcWeber Not sure I understand that question?