RFR: 8293650: Shenandoah: Support archived heap objects [v5]

[Y. Srinivas Ramakrishna]

On Thu, 15 Aug 2024 09:56:26 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> Noob question: can one prove that CDS archived objects will never exceed the size of a region? Or does the archive writer refuse to create a dump in that case? I will assume the latter for the purposes of the following remark:
>> 
>> When you walk over the objects allocated in the verifier loop further below at lines 2539-2543, I wonder if you should check that you always have a legitimate object starting and ending each alignment boundary, just to be super-paranoid.
>
> Typo fixed. 
> 
> Verifier checks objects are within the regions:
> https://github.com/openjdk/jdk/blob/da7311bbe37c2b9632b117d52a77c659047820b7/src/hotspot/share/gc/shenandoah/shenandoahVerifier.cpp#L143-L144
> 
> I think we reasoned that check is too expensive for the regular `shenandoah_assert_correct`. But there is a less used `shenandoah_assert_in_correct_region` that we can co-opt for this check. For testing, I disabled `MIN_ALIGNMENT` bailout, and caught the expected failure:
> 
> 
> #
> #  Internal Error (/Users/shipilev/Work/shipilev-jdk/src/hotspot/share/gc/shenandoah/shenandoahHeap.cpp:2541), pid=99715, tid=9987
> #  Error: Shenandoah assert_in_correct_region failed; Object end should be within the active area of the region
> 
> Referenced from:
>   no interior location recorded (probably a plain heap scan, or detached oop)
> 
> Object:
>   0x00000007c003ffe8 - safe print, no details
>   region: |    0|R  |BTE    7c0000000,    7c0040000,    7c0040000|TAMS    7c0000000|UWM    7c0000000|U   256K|T     0B|G     0B|S   256K|L     0B|CP   0
> 
> Raw heap memory:
> 0x00000007c003ffc8:   6f6e2074 61682074 61206576 7365206e   t not have an es
> 0x00000007c003ffd8:   616d6974 20646574 61727564 6e6f6974   timated duration
> 0x00000007c003ffe8:   00000001 00000000 001b64c8 0000001b   .........d......
> 0x00000007c003fff8:   74696e49 206c6169                     Initial
> 
> 
> Looking more at this, I think there might be an interaction with humongous threshold if it is smaller than region size. If CDS allocates the object that is larger than our humongous threshold, this new code would effectively allow a "humongous" object to reside in regular region. CDS would not know about this, because it thinks the largest possible object is `MIN_GC_REGION_ALIGNMENT`. I think we would just remove the tunable to avoid any corner cases: https://bugs.openjdk.org/browse/JDK-8338444.

Sounds good, thanks for checking this and tightening these issues!

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

PR Review Comment: https://git.openjdk.org/jdk/pull/20468#discussion_r1718632237