GC: two major pain point the compiler/druntime can help with

[Adam Wilson]

On Tuesday, 21 May 2024 at 12:07:14 UTC, deadalnix wrote:
> 2. The Current GC API touches memory all over the place.
>
> The current GC API loads a pointer to a GC object, then load 
> the vtbl, then load the method to call int he vtbl, and does 
> similar things in the TypeInfo API. All of these data are on 
> disparate part of the memory on their own pages.
>
> We designed our GC to touch only one page on the fast path. As 
> a result, we get 4x TLB and cache misses in the plumbing 
> between the application and the GC, causing the plumbing to to 
> be half the cost of an allocation !!!
>
> This API needs to be redesigned. The way it is usually done in 
> the wild is to make the allocator overridable using weak 
> functions. This allows to customize the allocator at link time 
> without paying an absurd cost like we do.

I discussed this with Walter last Thursday, you have his blessing 
to modify the API as you see fit. He doesn't know what you need 
so you'll have to make the modifications, but we can fast track 
it through the PR process once you're ready.