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

[Aleksey Shipilev]

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.

Three things:

1. Bug synopsis should generally reflect what is being done, not what the symptom is. There is a leeway: it can describe the _problem_ that is being solved.

2. See the comment, "Reclaim from tail". Have you verified reclaiming from head is fine? If not, I think it is better to find the tail first, then walk it backwards. In fact, maybe it is a good time to introduce an utility method in `ShenandoahHeapRegion` that tells the tail of HC chain. There is already `ShenandoahHeapRegion::humongous_start_region` that can have a symmetric `ShenandoahHeapRegion::humongous_end_region`.

3. Generally, it looks brittle to touch objects during any heuristics calculation due to these lifecycle problems. There is another instance of `ShenandoahHeapRegion::required_regions(obj->size() * HeapWordSize);` in `ShenandoahGenerationalHeuristics::choose_collection_set` -- is it affected by the same issue?

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

PR Review: https://git.openjdk.org/jdk/pull/26256#pullrequestreview-3019102674