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