useMalloc for standard GC

[arnetheduck]

Closes #15394

unoptimized, malloc-based allocator for the GC - uses less memory, is a
bit slower for small chunks, less code

[arnetheduck]

Using this branch halves the memory footprint of nimbus, as measured by RSS in linux (400 mb instead of 800).

It's not intended for production use really, more as a debugging tool - it's branched off the beginning of the 1.2 release cycle roughly, so can easily be applied to any version after that.

[Araq]

Does it support the alignment requirements that the conservative stack scan needs?

[arnetheduck]

Does it support the alignment requirements that the conservative stack scan needs?

well, it assumes 8-byte alignment on anything coming out of malloc and redefines pageIndex and boundary checking accordingly - seems to work no worse than the "normal" GC allocator, judging by GC tests and nimbus (which is a long-running memory-allocation-heavy process).

Nimbus is the reason this branch was written - we're having GC-related crashes and it's unclear what the culprit is: unfixed bugs in the cycle collector like #4851 and #10625 or the pointer tricks we sometimes subject the code to, that perhaps break the scanner.

[mratsim]

Closes #15394

[arnetheduck]

the test fails here are likely because this was branched off where 1.2.0 was released which might be missing some commits to update test scripts

[arnetheduck]

Oh, and with something like tcmalloc you regain most of the lost performance - there are a few obvious improvements one could make which probably would bring the performance up to par - in particular, this branch has a large per-allocation overhead that mostly could go away, but it was simply more easy to write it this way so that one wouldn't have to modify the rest of the gc

[Araq]

Ping @arnetheduck, can you please rebase?

[ringabout]

Sorry for messing up commits messages(maybe you can use force push or somethings to clean the commits messages)
I only fetch the latest commits, didn't change the codes.

[arnetheduck]

Sorry for messing up commits messages

I'm a bit unsure what you've done here? did you rebase against devel?

[ringabout]

yeah

[arnetheduck]

hm, the 32-bit issue might be legit, need to recheck some arithmetic

[stale]

This pull request has been automatically marked as stale because it has not had recent activity. If you think it is still a valid PR, please rebase it on the latest devel; otherwise it will be closed. Thank you for your contributions.