RFR: 8305896: Alternative full GC forwarding [v16]

Roman Kennke rkennke at openjdk.org
Tue May 2 16:54:24 UTC 2023


On Tue, 2 May 2023 15:25:10 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

> Hi Roman,
> 
> Small general concern, the last-last-ditch-GC fallback table may be impractical cost-wise. How large is that expected to grow? You pay 24+x (~48 on glibc with internal overhead) bytes per forwarded oop.
> 
> Very easy first-step mitigation: Let the table house the first n (1000-10000) nodes as an inline member array. Allocate nodes from there, only allocate spilloffs from C-heap. Allocation would be a lot faster and cheaper memory wise, and its just some lines of code.
> 

I did some experiments with the only jtreg test that seems to exercise the G1 serial compaction (and thus the fallback-table) (the test is: gc/stress/TestMultiThreadStressRSet.java). With fallback-table size 128 I'd typically end up with several dozens excess nodes, sometimes more than the base table size. Up to table size of 512 this reduces signicantly but still typically one to several dozen extra nodes. When I switched to table-size of 1024 the extra nodes count drops to below one dozen in most cases. I'll leave the table-size at this value until we find a good reason to extend it, ok?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/13582#issuecomment-1531813673


More information about the shenandoah-dev mailing list