Add Continuation direct transition support

[fengxue-IS]

• Cache jitGPR data in J9VMContinuation
• Wrap Continuation.execute call to force yield after completion
• Build Callin frame during first enterContinuation call
• added helper to copy Continuation data into J9VMThread structure

Closes: #15464

Signed-off-by: Jack Lu Jack.S.Lu@ibm.com

[tajila]

@fengxue-IS do the ppc jit failures still occur with these changes?

[gacholio]

This PR should also provide the walkContinuationStackFrames wrapper function.

[gacholio]

Still need to add the stack walk wrapper.

[fengxue-IS]

Per discussion with @LinHu2016, I included part of Lin's code to prepare a stack allocated J9VMThread for stackwalk with data from Continuation object, this helper will be shared by VM and GC.

[gacholio]

The VMHelpers change is not how I would like this done. Please create a wrapper for walkStackFrames as I've described above. It should be a C function, not an inline header function.

Also note that decompilationStack will also need to be swapped like other roots.

[fengxue-IS]

The current VMHelper function is what GC would need as they have code that specifically depends on a walkable J9VMThread passed to top level function which eventually would call walkStackFrames.

I can add a separate wrapper that would accept a continuation object and walkState, then stack allocate the J9VMThread/ELS and uses this api to copy the data and calls walkStackFrames in the end

[fengxue-IS]

Also note that decompilationStack will also need to be swapped like other roots.

do j2iFrame also need to be swapped?

[gacholio]

do j2iFrame also need to be swapped?

Yes.

[gacholio]

I can add a separate wrapper that would accept a continuation object and walkState, then stack allocate the J9VMThread/ELS and uses this api to copy the data and calls walkStackFrames in the end

Yes, this is what we'll need (think javacore). Will the wrapper be able to share the helper code? I dislike having multiple copies of this logic, particularly split between VM and GC.

[gacholio]

Feel free to remove the ifdefs from the VMHelpers code - we always have a JIT and always have FSD. Certainly don't propagate the ifdefs into the structure definition.

[gacholio]

Actually, the wrapper function should take the J9JavaVM rather than the current J9VMThread (which is NULL is some of the RAS code).

[LinHu2016]

Thanks @fengxue-IS for new walkContinuationStackFrames function, currently in GC there is no precompile option (#if JAVA_SPEC_VERSION >= 19), so could you please add a wrapper for the walkContinuationStackFrames() (the function is for java 19 only)?

[gacholio]

I was under the impression the GC could not use walkContinuationStackFrames in its current form, which is why I'm asking for the more generic helper.

[fengxue-IS]

I was under the impression the GC could not use walkContinuationStackFrames in its current form, which is why I'm asking for the more generic helper.

Discussed the logic with @LinHu2016 offline, GC have optimized their design to combine the different hierarchy into a single location on scanning Continuation object which allow them to directly consume the walkContinuationStackFrames API.

I will move code from copyJavaStacksFromContinuation directly into walkContinuationStackFrames and create a new wrapper in VMHelpers that perform the ifdef on Java version GC requires.

[gacholio]

OK, please add the J9JavaVM parameter to it as we need it to initialize the J9VMThread for use in the stack walk, and we can't depend on being able to fetch it from the current thread.

[gacholio]

Also, please zero initialize the ELS and J9VMThread to 0 at the start (using = { 0 }).

[fengxue-IS]

OK, please add the J9JavaVM parameter to it as we need it to initialize the J9VMThread for use in the stack walk, and we can't depend on being able to fetch it from the current thread.

We would need currentVMThread regardless to fetch the J9VMContinuation struct from the Continuation object via J9VMJDKINTERNALVMCONTINUATION_VMREF(vmthread, object) macro?

Edit: I guess I can use the J9VMJDKINTERNALVMCONTINUATION_VMREF_VM version which rely on J9JAVAVM_VMTHREAD()

[gacholio]

There should me a matching _VM version of the macro generated, I believe.

[fengxue-IS]

@gacholio what about the currentThread that walkStackFrames expect? do I also use the J9JAVAVM_VMTHREAD macro?

[gacholio]

The stack walker can handle the NULL current thread already so you can just pass it through.

[gacholio]

The case we're interested in handling is when javacore generation is signalled on a non-java thread, so in that case asking the VM for the current thread would not work.

All of this is assuming we will eventually want to display continuation stacks in the javacore.

[gacholio]

I'm not sure the macro will actually work in this case unless the GC can also handle a NULL vmThread.

Maybe for now leave the function signature the way it is and add an assert that the current thread is not NULL. We can consider this again when javacore support is added.

[gacholio]

Please squash the commits.

[gacholio]

jenkins test sanity.functional xlinux jdknext

[gacholio]

jenkins compile win jdk8,jdknext

[gacholio]

Jep425Tests_testVirtualThread_0 failure.

[fengxue-IS]

@gacholio can you please run the sanity suite against jdk19, I think jdknext is running with jdk20 which might not work as virtualthread is preview for Java 19

[tajila]

jenkins test sanity.functional xlinux jdk19