RFR: 8340171: CDS: Enhance bitmap truncation [v2]

[John R Rose]

On Mon, 16 Sep 2024 08:52:35 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> Current CDS archive ships multiple bitmaps. Archival/loading code makes a useful optimization: it truncates the bitmaps at the beginning when it is known the prefix contains many zeroes. The object sorting code additionally sorts the pointer-rich objects at the end of the archive, increasing the zero-prefix length.
>> 
>> This optimization works less efficiently after [JDK-8338912](https://bugs.openjdk.org/browse/JDK-8338912), which moved the (pointer-rich) roots array at the beginning of the archive. We need to enhance current bitmap handling mechanism to truncate bitmaps better.
>> 
>> This PR does two things: a) enables bitmap truncation for both leading and trailing zeros; b) sorts the oop-rich objects at the beginning, where the oop-rich roots array is.
>> 
>> CDS archive sizes:
>> 
>> 
>> # Before JDK-8338912
>> $ ls -la build/linux-x86_64-server-release/images/jdk/lib/server/*.jsa
>> 15450112 build/linux-x86_64-server-release/images/jdk/lib/server/classes.jsa
>> 15851520 build/linux-x86_64-server-release/images/jdk/lib/server/classes_nocoops.jsa
>> 
>> # After JDK-8338912: +8..12K regression in size
>> $ ls -la build/linux-x86_64-server-release/images/jdk/lib/server/*.jsa
>> 15462400 build/linux-x86_64-server-release/images/jdk/lib/server/classes.jsa
>> 15859712 build/linux-x86_64-server-release/images/jdk/lib/server/classes_nocoops.jsa
>> 
>> # After this fix: recovered to pre-JDK-8338912 levels
>> $ ls -la build/linux-x86_64-server-release/images/jdk/lib/server/*.jsa
>> 15450112 build/linux-x86_64-server-release/images/jdk/lib/server/classes.jsa
>> 15851520 build/linux-x86_64-server-release/images/jdk/lib/server/classes_nocoops.jsa
>> 
>> 
>> Additional testing:
>>  - [x] Linux x86_64 server fastdebug, `runtime/cds`, `tier1`
>>  - [x]  Linux x86_64 server fastdebug, `all`
>
> Aleksey Shipilev has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove excessive debugging logging

I'm racking my brain to figure out if there is some kind of regression test we could write to detect a future situation like this:  (a) Someone changes the AOT cache so that there is a burst of new oops or metadata pointers injected, and then (b) the pointer bitmap loses its clever compression.  How will we notice such a thing?

I have an idea; this is the best I've got ATM:  Print a log message that gives the density of one-bits in the pointer map (out of total map size).  Maybe also the density of non-zero WORDS in the pointer map.  It's a "figure of merit"; 50-100% would be awesomely good, 1% would be very bad .  Write a regression test that detects if that metric goes out of some reasonable range, for some representative workload.  It has to be a tentative failure, kind of like a test timeout or excessive pause time.

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

PR Comment: https://git.openjdk.org/jdk/pull/21010#issuecomment-2362897794