D Language Foundation January 2025 Quarterly Meeting Summary

[Steven Schveighoffer]

On Thursday, 10 April 2025 at 11:37:11 UTC, Mike Parker wrote:
> __The new GC__
>
> Luís said he'd spoken with Amaury at DConf about the new GC 
> implementation regarding ARM. The new GC assumed a page size of 
> 4K, but ARM had a different page size,  which could cause 
> higher-than-expected memory usage on ARM systems. He wanted to 
> follow up on the implementation's progress.
>
> I said no one at the meeting was up to speed on that. It would 
> have to be Steve or Amaury. I said I could put him in touch 
> with them and he could ask them (and I did).

Apologies on my memory, but I'm not sure if this conversation 
happened or not.

Technically, we use assumptions on the page size, so while it 
might not align with the system page size, the GC isn't going to 
fail to use the "Extra memory". We allocate 2MB pages (blocks), 
and then divide them up into what we think are pages (assuming 
4K). Where we may have issues is marking pages as "unused" to 
give back to the OS, I believe we will try to mark the 4k page as 
unused, and this might not work right. But as far as divvying up 
the memory, that does not rely on an OS/arch provided page size, 
it relies on constants in our code.

Adjusting the page size shouldn't be extremely difficult, but we 
may have issues with some metadata. i.e. a 4k slab of 8-byte 
allocations requires 512 bits for flagging each slot as 
"allocated". A 16k slab would require 2048 bits. Our metadata 
structure is 128 bytes (1024 bits) in size, and we really do not 
have a lot of bits to spare, let alone that many more.

I'm sure we can come up with a solution when the time comes. It 
might be as simple as -- no 8-byte allocations. Or we may just 
have to only give back memory in "4-page" chunks.

-Steve