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
