Free space does not work for huge heaps since often they are allocated on demand as a full page at a time. But if more than X huge pages have been allocated, it is probably a good time to initiate a major GC.
When the collector cooperates for a mutator it needs to mark any heap-collected objects that are stored within the mutator's data object. This prevents problems where these objects (which are essentially per-thread global roots) are incorrectly collected.
Attempt to prevent thrashing the GC during earley benchmark by:
- Allowing a larger max page size
- Only freeing huge pages. This prevents thrashing where pages are freed only to be immediately reallocated when the heap is grown after sweep.
Longer term it may be necessary to allow freeing of pages by being more intelligent about things.
Attempt to speed up gc_collector_mark_gray by forcing it to be inlined via a C macro. I am skeptical the compiler cannot do this already but the change seems to speed the earley benchmark up by several seconds.
- Increase page size
- Cache last page that had an allocation, and start from that page next time, if possible. This speeds up allocation on large heaps because we can avoid searching through the whole heap each time.
This is a commonly used function that the C compiler may be able to better optimize, such as inline, now that it is guaranteed to only be used within the gc.c module.
Use a reallocated memory buffer instead of malloc'd pairs. This should speed things up by reducing the number of allocations and by keeping mutations in contiguous sections of memory.
