Implement JVM_VirtualThreadHideFrames()

[thallium]

Hide some JVM TI events after notifyJvmtiHideFrames(true) is called.

Added a helper to decide whether a event should be dispatched.

Signed-off-by: Gengchen Tuo gengchen.tuo@ibm.com

Fixes: #16012

[thallium]

@fengxue-IS FYI
Currently the following events are hidden:

• Exception
• Exception Catch
• Field Access
• Field Modification
• Frame Pop
• Method Entry
• Method Exit

Other things to notice:

• In OpenJDK, in function with @JvmtiMountTransition annotation, the Exception Catch event is not sent but Exception event is still sent.
• OpenJDK seems to be hiding VirtualThread.mount() and VirtualThread.unmount(), need to do further verification on that.
• Events triggered by JNI method is not hidden yet, but should be easy to do?

[thallium]

@fengxue-IS can you please take a look

[fengxue-IS]

minor nit pick on formatting

[thallium]

With the change the events mentioned above are hidden which matches the behaviour to RI.

[fengxue-IS]

In OpenJDK, in function with @JvmtiMountTransition annotation, the Exception Catch event is not sent but Exception event is still sent.

ExceptionCatch have known issues in how it is triggered in RI, see #5785.
It does make sense that if RI is not hiding exception event, this maybe considered a error path so exception event shouldn't be hidden. I will double check this to confirm if we should match RI.

OpenJDK seems to be hiding VirtualThread.mount() and VirtualThread.unmount(), need to do further verification on that.

Have this been confirmed?

Events triggered by JNI method is not hidden yet, but should be easy to do?

JNI events that are equivalent to Java events should also be hidden (those that map the the same JVMTI_EVENT code in jvmtiHook.c.)

[thallium]

Have this been confirmed?

This is due to openjdk's implementation and is not part of the issue that this PR is trying to fix.

Also field access and modification event triggered by JNI is now hidden.

[fengxue-IS]

lgtm, the hiding of normal mount transition will be pursued as part of #16984

@babsingh please take a look

[babsingh]

• What testing was done to verify these changes?
• Do we plan to enable tests after this PR is merged?

++ @gacholio for review.

[thallium]

What testing was done to verify these changes?

I modified the VirtualThread.java to try to trigger some events after notifyJvmtiHideFrames() is called and see if any event is received by a JVMTI agent.

Do we plan to enable tests after this PR is merged?

No, I don't think there's a related test.

[gacholio]

If the goal here is to hide JVMTI events, the work should really be done in JVMTI, not at the hook dispatch points. Hooks can be used for more than just JVMTI.

[keithc-ca]

If the goal here is to hide JVMTI events, the work should really be done in JVMTI, not at the hook dispatch points. Hooks can be used for more than just JVMTI.

I agree.

[thallium]

If the goal here is to hide JVMTI events, the work should really be done in JVMTI, not at the hook dispatch points. Hooks can be used for more than just JVMTI.

Makes sense, I'll work on that.

[thallium]

Sorry I just realized I force pushed an old branch, should be fixed now.

[keithc-ca]

Please squash the commits; this modifies and then reverts changes, e.g. jvmtiExtensionMechanism.c.

[thallium]

@keithc-ca Squashed and addressed the changes, sorry about the mess.

[thallium]

test/hotspot/jtreg/serviceability/jvmti/stress/StackTrace/Suspended/GetStackTraceSuspendedStressTest.java

The above test is currently disabled. I saw a crash in JVM_VirtualThreadHideFrames while running this test locally.

JVMDUMP039I Processing dump event "gpf", detail "" at 2023/04/28 13:51:50 - please wait.
Unhandled exception
Type=Segmentation error vmState=0x00040000
J9Generic_Signal_Number=00000018 Signal_Number=0000000b Error_Value=00000000 Signal_Code=00000001
Handler1=00007FA00843E930 Handler2=00007FA008239400 InaccessibleAddress=0000000000000008
RDI=0000000000000000 RSI=0000000000000002 RAX=0000000000000004 RBX=0000000000285300
RCX=0000000000000000 RDX=0000000000000000 R8=0000000000285300 R9=00007FA004018A20
R10=0000000000000000 R11=00007FA0086FDD70 R12=00000000FFEE4210 R13=0000000000000001
R14=00007FA0085F171C R15=00007F9FB090F578
RIP=00007FA00864781B GS=0000 FS=0000 RSP=00007F9FB090F2B0
EFlags=0000000000010202 CS=0033 RBP=0000000000000000 ERR=0000000000000004
TRAPNO=000000000000000E OLDMASK=0000000000000000 CR2=0000000000000008
xmm0 00007f9fb090f560 (f: 2962289920.000000, d: 6.932919e-310)
xmm1 00007fa0085f1690 (f: 140449424.000000, d: 6.932992e-310)
xmm2 00000000001d7a00 (f: 1931776.000000, d: 9.544242e-318)
xmm3 00000000003f8630 (f: 4163120.000000, d: 2.056855e-317)
xmm4 00000000003f8710 (f: 4163344.000000, d: 2.056965e-317)
xmm5 00000000003f8718 (f: 4163352.000000, d: 2.056969e-317)
xmm6 00000000003f8710 (f: 4163344.000000, d: 2.056965e-317)
xmm7 00000000003f8718 (f: 4163352.000000, d: 2.056969e-317)
xmm8 0000000000284d41 (f: 2641217.000000, d: 1.304935e-317)
xmm9 0000000000260968 (f: 2492776.000000, d: 1.231595e-317)
xmm10 0000000000000003 (f: 3.000000, d: 1.482197e-323)
xmm11 0000000000000000 (f: 0.000000, d: 0.000000e+00)
xmm12 00000000001d7770 (f: 1931120.000000, d: 9.541000e-318)
xmm13 0000000000000000 (f: 0.000000, d: 0.000000e+00)
xmm14 0000000000000000 (f: 0.000000, d: 0.000000e+00)
xmm15 00007fa00861ab50 (f: 140618576.000000, d: 6.932992e-310)
Module=/root/openj9-openjdk-jdk20/build/linux-x86_64-server-release/images/jdk/lib/default/libjvm.so
Module_base_address=00007FA008627000 Symbol=JVM_VirtualThreadHideFrames
Symbol_address=00007FA008647780
Target=2_90_20230329_000000 (Linux 5.4.0-147-generic)
CPU=amd64 (8 logical CPUs) (0x3e884e000 RAM)
----------- Stack Backtrace -----------
JVM_VirtualThreadHideFrames+0x9b (0x00007FA00864781B [libjvm.so+0x2081b])
ffi_call_unix64+0x56 (0x00007FA0085CC016 [libj9vm29.so+0x1cc016])
ffi_call_int+0x1bc (0x00007FA0085CAFCC [libj9vm29.so+0x1cafcc])
_ZN37VM_DebugBytecodeInterpreterCompressed3runEP10J9VMThread+0x1c0fd (0x00007FA008500CBD [libj9vm29.so+0x100cbd])
debugBytecodeLoopCompressed+0xd5 (0x00007FA0084E4BB5 [libj9vm29.so+0xe4bb5])
 (0x00007FA008559BB2 [libj9vm29.so+0x159bb2])

@babsingh changing notifyJvmtiHideFrames(false) to vthread.notifyJvmtiHideFrames(false) will make the crash gone and fail as a duplication of #17123. Looks like hotspot always does the operation on the current thread.

[fengxue-IS]

@thallium can you confirm that the updated code still passes tests you've wrote.

Also, should we consider add those test to the Java20andUp @babsingh ?

[babsingh]

Also, should we consider add those test to the Java20andUp @babsingh ?

Yes, that's a good idea. More testing is always preferred. Adding them to the sanity.functional suite will help us identify breakages early-on. To not delay the merge of this PR, the new tests can added in a separate PR.

[thallium]

can you confirm that the updated code still passes tests you've wrote.

@fengxue-IS Yes

[fengxue-IS]

@keithc-ca all previous review comments have been addressed, can you take another look

[keithc-ca]

Jenkins test sanity amac jdk17,jdk20