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

[Aleksey Shipilev]

On Thu, 15 Aug 2024 02:11:53 GMT, Y. Srinivas Ramakrishna <ysr at openjdk.org> wrote:

>> src/hotspot/share/gc/shenandoah/shenandoahHeap.cpp line 2503:
>> 
>>> 2501:   // We need to make sure it looks like regular allocation to the rest of GC.
>>> 2502: 
>>> 2503:   // CDS code would guarantee no objects straggle multiple regions, as long as
>> 
>> straggle -> straddle
>
> 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.

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

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