Investigate into a way to consolidate reconcile the Allocator trait and a collection trait

[nekevss]

The allocator_api2 crate exposes Rust's Allocator trait, which is an experimental trait for defining allocators.

It would be interesting if we were able to take advantage of the Allocator trait with a Collector super trait of our own. Something akin to:

trait Collector : Allocator { 
    // Methods to be determined.
}

This would mean that we could use third party collection libraries that expose an allocator API of their own.

Potential concerns

• Is doing this even possible in a generic way across multiple collectors?
• Is it even safe to do this and use collections that may not be properly designed for this use case?

[shruti2522]

I spent some time looking through the code. The current GC is non-moving, which avoids safety issues around using GC as an allocator. But i am still unsure about the root tracking part, for ex., a Vec<T, GcAllocator> would not automatically keep its backing allocation alive during collection, so GC backed collections would probably need to implement Trace.

Collector: Allocator setup seems possible, mark sweep collector seems easier to adapt while pool based collectors feel a bit trickier to me but they are still doable if each provides its own allocator. Also, Allocator requires &self, while the current allocation paths use &mut self. Would it make sense to expose the allocator through a thin wrapper like GcAllocator<'gc>(&'gc MarkSweepGarbageCollector) instead of adding interior mutability? not sure if that causes other issues, I would like to know your thoughts on this approach

[Divinesoumyadip]

I’ve completed an audit of the current allocation paths in the oscars crate.

I confirmed that while src/alloc/arena/mod.rs still relies on an exclusive &mut self signature for alloc, the boa_mempool (and src/alloc/mempool/mod.rs) already provides a template for solving this. By wrapping the underlying pools in a RefCell, MemPoolAllocator successfully exposes a &self API for public allocations.

Following this established internal pattern, we can satisfy the Allocator trait requirements by using a similar 'bridge' wrapper with interior mutability.
Regarding the safety of third-party collections (like Vec<T, GcAllocator>): The primary risk is the backing allocation not being seen by the GC. I propose we research a Handle<T> or GcBox<T> wrapper that implements Trace. This would ensure that even if the collection itself isn't GC-aware, the objects inside remain rooted during a sweep.

I'm a GSoC 2026 aspirant and would love to help implement a Proof of Concept for this bridge.

[nekevss]

I think I'm fine with closing this out after #15.

There's serious issues with this approach, and it's ultimately will not work for multiple collectors.