JDK-8034249 : need more workarounds for suspend equivalent condition issue
  • Type: Bug
  • Component: hotspot
  • Sub-Component: jvmti
  • Affected Version: 8,9
  • Priority: P3
  • Status: Resolved
  • Resolution: Fixed
  • OS: generic
  • CPU: generic
  • Submitted: 2014-02-12
  • Updated: 2017-11-29
  • Resolved: 2014-02-18
The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.
8u152Fixed 9 b04Fixed
Related Reports
Relates :  
This issue was discussed in the review thread for:

The issue is important to fix as a part of the Test Stabilization project.

Please, see my reply to Dan below.

Thanks, Dan!
Some comments below.

On 2/4/14 7:48 AM, Daniel D. Daugherty wrote:
> On 2/4/14 4:13 AM, serguei.spitsyn@oracle.com wrote:
>> Please, review the fix for:
>>   https://bugs.openjdk.java.net/browse/JDK-8032223
>> Open webrev:
>> http://cr.openjdk.java.net/~sspitsyn/webrevs/2014/hotspot/8032223-JVMTI-FRAME.1/
> src/share/vm/prims/jvmtiEnvBase.hpp
>     No comments.
> src/share/vm/prims/jvmtiEnv.cpp
>     No comments beyond David's tweak to the comment.

Will fix it before push.

> For future work...
> Looks like these VM ops also need the liveness check on the
> target JavaThread:
>     VM_GetOwnedMonitorInfo
>     VM_GetStackTrace
> JvmtiEnv::GetStackTrace() looks like it has the same
> is_thread_fully_suspended() flaw...

I know about this.
There are even more issues:

I'll check if we can use an existing bug to add this extra request.
Otherwise, will file new one.


> Dan
>> Summary:
>>   This is the second round of review for this issue.
>>   But it was decided that the JDK-8032223 must be used to cover it instead of the JDK-6471769.
>>   The 8032223 was initially closed as a dup of 6471769 but it has been re-open now.
>>   There is a general issue in the suspend equivalent condition mechanism:
>>   Two subsequent calls to the JvmtiEnv::is_thread_fully_suspended() may return different results:
>>     - 1-st: true
>>     - 2-nd: false
>>   This suspend equivalent issue is covered by another bug:
>>     https://bugs.openjdk.java.net/browse/JDK-6280037
>>   The bug to fix in this review is a specific manifestation of the 6280037
>>   in the JVMTI GetFrameCount() that has a major impact on the SQE nightly.
>>   It is on the Test Stabilization radar as well as the 6280037.
>>   There are many tests intermittently failing because of this.
>>   I've also decided to fix the same issue in the JVMTI GetFrameLocation() as well.
>>   The JVMTI GetFrameCount() spec tells:
>>     "If this function is called for a thread actively executing bytecodes (for example,
>>      not the current thread and not suspended), the information returned is transient."
>>   So, it is Ok to call the GetFrameCount() for the non-suspended target thread.
>>   To achieve safety, the frame count for non-suspended threads is calculated at a safepoint.
>>   It should be Ok and more safe to do the same for suspended threads as well.
>>   There should be no big performance impact because it is already on a slow path.
>>   It is still important to avoid safepointing when the target thread is current.
>>   The bug 6280037 should go out of the Test Stabilization radar (remove the svc-nightly label)
>>   as the most of the impacted tests must be covered by the 8032223.
>> Testing:
>>   In progress:
>>     - nsk.jvmti, nsk.jdi, nsk.jdwp
>>     - JTreg com/sun/jdi
>> Thanks,
>> Serguei

Added the noreg label for the jdk8u-dev backport. There are existing nsk.jvmti.testlist tonga tests that provide the necessary test coverage for this fix: nsk/jvmti/GetStackTrace/getstacktr00* nsk/jvmti/GetCurrentContendedMonitor/contmon00* nsk/jvmti/GetOwnedMonitorInfo/ownmoninf00* nsk/jvmti/unit/StackTrace/JvmtiTest nsk/jvmti/unit/functions/nosuspendMonitorInfo/JvmtiTest nsk/jvmti/unit/functions/nosuspendStackTrace/JvmtiTest

This kind of fix is not needed for NotifyFramePop. The call to is_thread_fully_suspended() is used there not for safety but to comply with the JVMTI spec.

This issue needs a fix similar to the one suggested for the JDK-8032223.