RFR: 8360288: Shenandoah crash at size_given_klass in op_degenerated [v2]

[William Kemper]

On Mon, 14 Jul 2025 23:32:55 GMT, William Kemper <wkemper at openjdk.org> wrote:

>> Both degenerated and full GCs unload classes before reclaiming unmarked humongous objects. This may result in a null klass pointer dereference when asking humongous objects for their size.
>
> William Kemper has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Reclaim humongous regions from start to end (do not use oop::size).
>  - Revert "STW collections cannot unload classes before reclaiming garbage"
>    
>    This reverts commit ae8079386eb34cf1351534ede7d7df8f81b50174.

Thanks for the review. 
1. I will update the synopsis when we settle on the approach to solve this issue. To be clear, by "synopsis" you mean the description of the pull request?
2. Yes, I looked at all usages of `ShenandoahHeapRegion::is_humongous*` and didn't see any cases that would be affected by this change. All of the GHA and pipeline tests passed. The comment is over 7 years old. Also, this code to make immediate trash of unmarked humongous objects only runs on a safepoint (final-mark, degen or full-gc). I will, however, run the jtreg tests again with trace logging enabled out of an abundance of caution.
3. Yes, I agree, the code is brittle. For reasons lost to history, STW collections (degen and full-gc) perform weak roots, weak refs and class unloading _before_ choosing the collection set (this order is the reverse of concurrent GCs). My initial attempt to put these steps in the same order for STW collections met with... resistance. Many assertions failed for what looks like erroneous reasons. The other instance of `ShenandoahHeapRegion::required_regions(obj->size() * HeapWordSize);` is safe here because this is a marked humongous object (and should _not_ have its class unloaded). I can revisit my initial approach, but I'm not sure I want to open that can of worms. I'd rather spend the time on removing STW collections.

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

PR Comment: https://git.openjdk.org/jdk/pull/26256#issuecomment-3074617563