Pass threadObject to walkContinuationStackFrames

[babsingh]

threadObject is required in jvmtiFollowReferences to get thread
specific details such as the TID.

So, threadObject needs to be passed via walkContinuationStackFrames
so that it is accessible in jvmtiFollowReferences.

walkContinuationStackFrames is invoked either for a
[1] J9VMContinuation in the Continuation object or
[2] J9VMThread->currentContinuation.

In [1], if the Continuation is fully mounted, then it stores the state
of the CarrierThread. Otherwise, it stores the state of the
VirtualThread.

In [2], if J9VMThread->currentContinuation is not NULL, then it stores
the state of the CarrierThread because the VirtualThread is mounted on
the J9VMThread. The CarrierThread is retrieved from
J9VMThread->carrierThreadObject.

We have assumed that the state of the Continuation or J9VMContinuation
doesn't change while walkContinuationStackFrames is invoked i.e. the
VirtualThread shouldn't be mounted or unmounted. Otherwise, the values
of the VirtualThread and CarrierThread objects accessed via the
Continuation object and J9VMThread->carrierThreadObject can vary and
cause a crash during walkContinuationStackFrames.

Related: #17712

[babsingh]

There are VM, GC and JIT changes in this PR. @fengxue-IS @0xdaryl @dmitripivkine Requesting your review.

fyi @tajila

[babsingh]

@fengxue-IS I have addressed all of your feedback.

[fengxue-IS]

LGTM

[0xdaryl]

JIT changes look fine.

[babsingh]

The last push just updated the commit message to reflect the latest changes. Also, the PR description was updated.

[babsingh]

jenkins test sanity zlinux jdk11,jdk21

[babsingh]

jenkins compile win jdk11,jdk21

[amicic]

While I see an improvement, isn't there still a problem JVMTI walking stack frames while they are potentially changing (of a mounted VT)?
Concurrent GCs have a whole protocol to ensure they don't walk it, while VT is mounted (and VT does not get mounted while GC walks it).
A more basic question for my understanding: how is this functionality safe even with just ordinary/platform threads without ensuring the thread does not have VM access (for example by acquiring exclusive VM access)?

[babsingh]

re #18180 (comment):

There is synchronization code which prevents virtual threads to be mounted or unmounted while they are being inspected via JVMTI.

[babsingh]

The PR builds look good except the known failure (more details below).

https://openj9-jenkins.osuosl.org/job/Test_openjdk21_j9_sanity.functional_s390x_linux_Personal/38/

cmdLineTester_criu_random_0 failure is a known issue: #14974 (comment).

19:58:46  Testing: Second Restore of Criu Checkpoint Image
19:58:46  Test start time: 2023/10/04 23:58:46 Coordinated Universal Time
19:58:46  Running command: bash /home/jenkins/workspace/Test_openjdk21_j9_sanity.functional_s390x_linux_Personal_testList_0/aqa-tests/TKG/../../jvmtest/functional/cmdLineTests/criu/criuRandomScript.sh /home/jenkins/workspace/Test_openjdk21_j9_sanity.functional_s390x_linux_Personal_testList_0/aqa-tests/TKG/../../jvmtest/functional/cmdLineTests/criu /home/jenkins/workspace/Test_openjdk21_j9_sanity.functional_s390x_linux_Personal_testList_0/openjdkbinary/j2sdk-image/bin/java " -Denable.j9internal.checkpoint.security.api.debug=true " "SecondRestore"
19:58:46  Time spent starting: 12 milliseconds
19:58:46  Time spent executing: 35 milliseconds
19:58:46  Test result: FAILED
19:58:46  Output from test:
19:58:46   [OUT] start running script
19:58:46  >> Success condition was not found: [Output match: Different random values]
19:58:46  >> Success condition was not found: [Output match: Post-checkpoint]
19:58:46  >> Success condition was not found: [Output match: Second Restore]
19:58:46  >> Failure condition was not found: [Output match: CRIU is not enabled]
19:58:46  >> Failure condition was not found: [Output match: Operation not permitted]
19:58:46  >> Success condition was not found: [Output match: Thread pid mismatch]
19:58:46  >> Success condition was not found: [Output match: do not match expected]
19:58:46  >> Success condition was not found: [Output match: Unable to create a thread:]
19:58:46  >> Failure condition was not found: [Output match: Can't open dir cpData: No such file or directory]
19:58:46  >> Failure condition was not found: [Output match: Could not dump the JVM processes, err=-70]
19:58:46  >> Failure condition was not found: [Output match: User requested Java dump using]

[amicic]

re #18180 (comment):

There is synchronization code which prevents virtual threads to be mounted or unmounted while they are being inspected via JVMTI.

This is good, but my original concern was more about the other way around - walking even if VT is already mounted. This change makes sure that a proper threadObject was snapshotted ahead of walk, but seems like JVMTI proceeds with the walk (of a stack that is potentially changing).

Another thing I'm curios about is the details of that synchronization - is there something we can share with Concurrent GC synchronization. It is outside of scope of these change - something we can talk about later, in person.

[babsingh]

but seems like JVMTI proceeds with the walk (of a stack that is potentially changing).

In this case, JVMTI will either halt the thread or acquire exclusive VM access to prevent the thread stack from changing. In jvmtiFollowReferences, we acquire exclusive VM access.

is there something we can share with Concurrent GC synchronization

@LinHu2016 and @fengxue-IS had a discussion about this in the past. JVMTI synchronization increments a counter or spins until the counter conditions are met. JVMTI synchronization is blocking and heavily dependent on spinning. The GC took a passive (non-blocking) approach to skip.

[babsingh]

@amicic @dmitripivkine @0xdaryl Can I ask one of you to merge this PR if everything looks good?

[dmitripivkine]

Failure in s390 build is unrelated (CRIU issue)