RFR: 8217618: JVM TI SuspendThread doesn't suspend the current thread before returning

[Daniel D. Daugherty]

On 1/24/19 9:46 PM, David Holmes wrote:
> Bug: https://bugs.openjdk.java.net/browse/JDK-8217618
> webrev: http://cr.openjdk.java.net/~dholmes/8217618/webrev/

src/hotspot/share/runtime/thread.cpp
     L2364: // Self-suspension will happen on the transition out of the vm.
         This comment is no longer accurate and should be deleted.

     L2365: // Catch "this" coming in from JNIEnv pointers when the 
thread has been freed
         This comment should have been deleted by the Thread-SMR project.
         Do you mind deleting it now?

test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/hotswap/HS202/hs202t002/hs202t002.cpp
     No comments.

test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/sampling/SP05/sp05t003/sp05t003.cpp
     No comments.


Thumbs up! No new webrev needed even if you decide to delete the
comments I flagged above.

Dan

>
> Lots of analysis in the bug report. Bottom line: SuspendThread of the 
> current thread was not actually suspending the thread until it hit 
> specific thread-state transitions. That meant that SuspendThread would 
> actually return and continue executing native code whilst suspended, 
> in violation of the specification for it.
>
> The fix is quite simple: in java_suspend() we check for the current 
> thread and call java_suspend_self().
>
> Testing:
>  - Any test that looked like it referred to thread suspension
>   - hotspot/jtreg/vmTestbase/nsk/jvmti/*
>   - jdk/
>      com/sun/jdi/*
>      java/lang/ThreadGroup/Suspend.java
> java/lang/management/CompositeData/ThreadInfoCompositeData.java
>      java/lang/management/ThreadMXBean/*
>      java/nio/channels/SocketChannel/SendUrgentData.java
> java/util/logging/LogManager/Configuration/TestConfigurationLock.java
>
>  - Mach 5 tiers 1-3 (in progress)
>
> Two tests were found to be erroneously relying on SuspendThread 
> returning whilst suspended:
>
> - vmTestbase/nsk/jvmti/scenarios/sampling/SP05/sp05t003/sp05t003.cpp
>
> The test updated a shared counter after the SuspendThread call, but it 
> needed to be updated before the call.
>
> - vmTestbase/nsk/jvmti/scenarios/hotswap/HS202/hs202t002/hs202t002.cpp
>
> The test was using a 0 return value from SuspendThread as an indicator 
> that the thread was in the suspended state - but that value can't be 
> seen until after SuspendThread returns, which is after the thread is 
> resumed. So I ripped out the custom state tracking logic and replaced 
> with a simple check of GetThreadState.
>
> Thanks,
> David