search

eclipse-openj9 / openj9

Eclipse OpenJ9: A Java Virtual Machine for OpenJDK that's optimized for small footprint, fast start-up, and high throughput. Builds on Eclipse OMR (https://github.com/eclipse/omr) and combines with the Extensions for OpenJDK for OpenJ9 repo.
Other
3.27k stars 721 forks source link

Loom: JVMTI stackwalk related API support #15759

Closed fengxue-IS closed 1 year ago

fengxue-IS commented 2 years ago

Part of #15183

// JVMTI APIs
GetLocal(Object|Instance|Int|Long|Float|Double)
SetLocal(Object|Int|Long|Float|Double)
NotifyFramePop
GetFrameCount
GetFrameLocation
GetThreadListStackTraces
GetStackTrace
GetCurrentContendedMonitor
GetOwnedMonitorInfo
GetOwnedMonitorStackDepthInfo
GetAllStackTraces

Handle Yielded Virtual Threads

If a virtual thread is yielded, it won't have a carrier thread i.e. it is not associated to a J9VMThread. For a yielded virtual thread, helperStackAllocateVirtualThread will stack allocate a J9VMThread and fake-mount the virtual thread on it. Assumption: Existing JVMTI functions should work with the stack-allocated J9VMThread to inspect a yielded virtual thread.

Stackwalking will be done either using the existing API vm->walkStackFrames or new API walkContinuationStackFrames provided in ContinuationHelpers.cpp, in order for all jvmti code to access the new API, it will have to be added to vm->internalVMFunctions

Currently we purpose to divide the walkContinuationStackFrames API to move the J9VMThread init code into a new helper which can be used by any JVMTI function which have multi-layer abstraction between the thread struct creation and call to walkStackFrames (ex. code that uses jvmtiInternalGetStackTrace) so they can stack allocate the structures locally and use the helper to copy fields from contination. (Note: due to jvmti code being written in C, it will not be able to include hpp helpers from ContinuationHelpers.hpp hence the new helper will also have to be added to J9InternalVMFunctions, we may choose to just modify jvmtiInternalGetStackTrace to accept a contination object and uses walkContinuationStackFrames directly.

see https://github.com/eclipse-openj9/openj9/issues/15183#issuecomment-1219243366 https://github.com/eclipse-openj9/openj9/issues/15183#issuecomment-1219287248 for more context

fengxue-IS commented 2 years ago

@thallium is currently working on GetFrameCount

fengxue-IS commented 2 years ago

@thallium can you take a look at GetStackTrace, should be similar to GetFrameCount, though you will need to modify jvmtiInternalGetStackTrace to accept continuation and use the helper walkContinuationStackFrames for VirtualThreads

fengxue-IS commented 2 years ago 
jvmtiNotifyFramePop
GetLocal(Object|Instance|Int|Long|Float|Double)
SetLocal(Object|Int|Long|Float|Double)

should need the same work as well to check if thread is virtual and fetch continuation object from thread for unmounted virtual thread, changes also have to be made to findDecompileInfo same as jvmtiInternalGetStackTrace

fengxue-IS commented 2 years ago

Given the dup of jvmti functionality between standard jvmti and jvmti extension, should we dup the changes to jvmti in OpenJ9 jvmti extension? ie jvmtiGetStackTraceExtended and etc... @babsingh

babsingh commented 2 years ago

should we dup the changes to jvmti in OpenJ9 jvmti extension?

can you specify what exactly will be duplicated? if the duplication can't be avoided, the only option will be to duplicate it.

fengxue-IS commented 2 years ago

For API that have 2 versions, we should make the same change to the following, right?

jvmtiGetStackTraceExtended
jvmtiGetAllStackTracesExtended
jvmtiGetThreadListStackTracesExtended
jvmtiInternalGetStackTraceExtended
babsingh commented 2 years ago

For API that have 2 versions, we should make the same change to the following, right?

Yes, they will need identical changes to support virtual threads.

fengxue-IS commented 1 year ago

Closing as all APIs listed have been merged. For any issues with test, please open new issue with specific test failure