On Mon, 20 Jul 2026 03:39:54 GMT, David CARLIER <[email protected]> wrote:
>> The test added in JDK-8387718 (#31772) fails when run with the virtual >> thread factory, on Linux and Windows, x64 and aarch64. >> >> The failure is in the test's expectation, not in the VM. GetLocalLong/Double >> with slot == INT_MAX still return JVMTI_ERROR_INVALID_SLOT as expected. But >> SetLocalLong/Double return JVMTI_ERROR_OPAQUE_FRAME on a mounted virtual >> thread: the runner() frame is inside a continuation, and >> VM_BaseGetOrSetLocal::doit() rejects a set at depth != 0 in a continuation >> frame before the slot bounds check is ever reached. On a platform thread >> there is no continuation, so the set reaches the slot check and returns >> INVALID_SLOT like the get accessors. >> >> Since the set accessors cannot reach the overflow check on a virtual thread, >> the test skips the set sub-tests there rather than asserting a second error >> code. The Java side passes Thread.currentThread().isVirtual() to the agent, >> which runs GetLocalLong/Double in both modes and adds SetLocalLong/Double >> only on a platform thread. Every accessor that runs still requires >> INVALID_SLOT, so the original overflow is exercised on platform threads and >> the get path covers it on virtual threads. >> >> Testing: >> >> - [x] serviceability/jvmti/GetLocalVariable/GetSetLocalSlotOverflow.java >> passes on platform threads (all four accessors return INVALID_SLOT) >> - [x] Passes with -testThreadFactory:Virtual (get accessors return >> INVALID_SLOT, set skipped), reproducing then clearing the reported failure >> - [x] linux-x86_64 fastdebug >> >> --------- >> - [x] I confirm that I make this contribution in accordance with the >> [OpenJDK Interim AI Policy](https://openjdk.org/legal/ai). > > David CARLIER has updated the pull request incrementally with one additional > commit since the last revision: > > Skip SetLocal sub-tests on virtual threads test/hotspot/jtreg/serviceability/jvmti/GetLocalVariable/libGetSetLocalSlotOverflow.cpp line 70: > 68: // On a mounted virtual thread the runner() frame is in a continuation, > so > 69: // SetLocal at depth != 0 is rejected with JVMTI_ERROR_OPAQUE_FRAME > before the > 70: // slot check runs -- it never exercises the overflow, so skip it there. We generally do not discuss continuations in comments like this. JVMTI does not support SetLocal being used on anything other than the topmost from of a virtual thread. The spec wording is: > The SetLocalXXX functions may be used to set the value of a local variable > in the topmost frame of a virtual thread suspended at an event. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/31965#discussion_r3616252317
