RFR: 8370198: Test gc/arguments/TestShrinkHeapInSteps.java crashed: assert(left >= right) failed: avoid underflow
Stefan Karlsson
stefank at openjdk.org
Thu Nov 20 09:21:20 UTC 2025
On Wed, 19 Nov 2025 15:39:27 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:
> Add an early-return for outside-heap address in `CollectedHeap::is_in` API.
>
> While investigating this failure (JDK-8370198), I realized that some java-threads (compiler-threads) in `native` state can invoke `CollectedHeap` APIs. Since heap-resizing occurs inside safepoint but java-threads in `native` state just ignore safepoint, I have added some assert to catch such dangerous uses, where the return value might not be stable.
>
> Test: tie1-5; can't reproduce the JDK-8370198 with or without this patch for >8000 runs.
This is quite conspicuous. Could this the addition be added to a function (or macro) so that the check becomes a one-liner. We have a similar function inside the ZGC runtime barriers. See:
template <typename ZBarrierSlowPath>
inline zaddress ZBarrier::barrier(ZBarrierFastPath fast_path, ZBarrierSlowPath slow_path, ZBarrierColor color, volatile zpointer* p, zpointer o, bool allow_null) {
z_verify_safepoints_are_blocked();
... < rest of the function >
I don't understand why we would want to put this check between the two range changes. Is there a reason why the added check couldn't be done at the beginning of the function?
-------------
PR Review: https://git.openjdk.org/jdk/pull/28393#pullrequestreview-3486554067
More information about the hotspot-gc-dev
mailing list