Allow objects to span multiple contiguous blocks for bump allocator #1298
Conversation
|
Did you want me to run a perf analysis of this or no? |
I think this is straightforward enough. But if you want, you can measure the probability of "the newly acquired block is right after the current block". I think it should be 100% for SemiSpace, GenCopy and GenImmix if both the application and the GC are single-threaded (i.e. a single mutator + a single GC worker thread). But it may well be 0% if it is multi-threaded. |
|
It's not necessarily a 100% because it could be a new chunk. But yes, close to 100% for single-threaded GC (or mutator for that matter). I just meant since it's a change to the slow-path, to evaluate the perf implications of it. |
|
Closing PR because it makes the mutator much more noisier without any benefit. Note that this was somewhat expected since this PR was more for the single-threaded case and not the multi-threaded case. This is SemiSpace running with 1.5x SemiSpace minheap. 
|
|
This is just an optimization/fix for a pathological case where there is only one allocating thread and the object frequently cannot fit into the rest of the current allocation buffer. When you have multiple threads but only one is actively allocating, we may also see an improvement. The improvement may not be from allocation throughput, as with the patch, we just save some slow path allocations. But we could get improvement from better memory utilization. |
|
Well yes. I have measured improvements for lusearch with single-threaded GC. But the above was the multi-threaded GC case. |
No description provided.