On Wed, 28 Oct 2026 23:39:26 GMT, Shiv Shah <[email protected]> wrote:
> With the virtual thread factory main runs on a virtual thread and > AsyncGetCallTrace keeps walking into the carrier, GetStackTrace stops at the > continuation entry. So the two never had the same number of frames there. > AsyncGetCallTrace itself is left alone, profilers build on what it returns > today and the replacement API is its own effort. > > The test now runs the check on a platform thread and on a virtual thread it > starts itself, whatever main runs on. Platform stays the exact comparison. On > the virtual thread the GetStackTrace frames have to be a prefix of the > AsyncGetCallTrace frames and the next frame has to be > Continuation.enterSpecial. With -XX:-VMContinuations both lists are the same > and that passes too. The virtual ProblemList entry is gone. > > --- > > Testing: > - [x] The test five times on linux-x64 and linux-aarch64 debug with the > platform factory, the virtual factory and -XX:-VMContinuations, plus tier1-3 > on both > > > --------- > - [x] I confirm that I make this contribution in accordance with the [OpenJDK > Interim AI Policy](https://openjdk.org/legal/ai). The fix looks okay in general. I've posted one suggestion though. test/hotspot/jtreg/serviceability/AsyncGetCallTrace/libAsyncGetCallTraceTest.cpp line 207: > 205: > 206: JNIEXPORT jboolean JNICALL > 207: Java_MyPackage_ASGCTBaseTest_checkAsyncGetCallTraceCall(JNIEnv* env, > jclass cls, jboolean is_virtual) { There is no need in this extra boolean argument. There are other ways to identify thread as virtual, e.g.: - `trace.num_frames > gstCount` - `env->IsVirtualThread(thread)` ------------- PR Review: https://git.openjdk.org/jdk/pull/33617#pullrequestreview-5745401863 PR Review Comment: https://git.openjdk.org/jdk/pull/33617#discussion_r4449441796
