RFR: JDK-8147447: [TESTBUG] serviceability/tmtools/jstack/WaitNotifyThreadTest.java test fails

[serguei.spitsyn at oracle.com]

On 1/21/16 07:36, Daniel D. Daugherty wrote:
> On 1/21/16 8:11 AM, Staffan Larsen wrote:
>>> On 21 jan. 2016, at 15:33, Alexander Kulyakhtin 
>>> <alexander.kulyakhtin at oracle.com> wrote:
>>>
>>> Staffan,
>>>
>>> Would it be sufficient to modify the code so that isCompMode() 
>>> returns true if and only if the -Xcomp option is present and is not 
>>> followed by the -Xmixed option?
>> Maybe, but that looks fragile. What if there is another option that 
>> implicitly enables compile mode?
>
> Even if the VM is in -Xmixed mode, code could get compiled and
> the stack trace output would show the compiled frame version
> and not the interpreted frame version. So:
>
> -Xint mode   - the compiled frame version will not be seen
> -Xmixed mode - both versions may be seen depending on compile
>                thresholds and other factors
> -Xcomp mode  - the compiled frame version will be seen

We need to be careful here. It is only true if the JVMTI is not used.

It is still possible to see the interpreted frames if some JVMTI events 
like SingleStep or MethodEntry are enabled.
In such cases, no matter what options the VM was started with, the 
interpreted frames still can be observed.

http://docs.oracle.com/javase/8/docs/platform/jvmti/jvmti.html#capability

Frequently, the addition of a capability may incur a cost in execution 
speed, start up time, and/or memory footprint. Note that the overhead of 
using a capability is completely different than the overhead of 
possessing a capability. Take single stepping as an example. When single 
stepping is on (that is, when the event is enabled and thus actively 
sending events) the overhead of sending and processing an event on each 
instruction is huge in any implementation. However, the overhead of 
possessing the capability may be small or large, depending on the 
implementation. Also, when and if a capability is potentially available 
depends on the implementation. Some examples:

  * One VM might perform all execution by compiling bytecodes into
    native code and be unable to generate single step instructions. In
    this implementation the capability can not be added.
  * Another VM may be able to switch execution to a single stepping
    *interpreter* at any time. In this implementation, having the
    capability has no overhead and could be added at any time.
  * Yet another VM might be able to choose a bytecode compiling or
    single stepping capable *interpreted* execution engine at start up,
    but be unable to switch between them. In this implementation the
    capability would need to be added during the |OnLoad| phase (before
    bytecode execution begins) and would have a large impact on
    execution speed even if single stepping was never used.
  * Still another VM might be able to add an "is single stepping on"
    check into compiled bytecodes or a generated *interpreter*. Again in
    this implementation the capability would need to be added during the
    |OnLoad| phase but the overhead (a test and branch on each
    instruction) would be considerably l


Thanks,
Serguei

>
> Dan
>
>
>>
>>> Best regards,
>>> Alexander
>>>
>>> ----- Original Message -----
>>> From: staffan.larsen at oracle.com
>>> To: alexander.kulyakhtin at oracle.com
>>> Cc: serviceability-dev at openjdk.java.net
>>> Sent: Thursday, January 21, 2016 5:20:14 PM GMT +03:00 Iraq
>>> Subject: Re: RFR: JDK-8147447: [TESTBUG] 
>>> serviceability/tmtools/jstack/WaitNotifyThreadTest.java test fails
>>>
>>> isCompMode() will fail if the VM is started with both -Xcomp and 
>>> -Xmixed.
>>>
>>> We need to find a better way to check if compiled mode is being 
>>> used. Perhaps System.getProperty("java.vm.info").contains("compiled”) ?
>>>
>>> /Staffan
>>>
>>>> On 19 jan. 2016, at 11:59, Alexander Kulyakhtin 
>>>> <alexander.kulyakhtin at oracle.com> wrote:
>>>>
>>>> Hi,
>>>>
>>>> Could you, please, review this minor test-only change
>>>>
>>>> CR: https://bugs.openjdk.java.net/browse/JDK-8147447 "[TESTBUG] 
>>>> serviceability/tmtools/jstack/WaitNotifyThreadTest.java test fails"
>>>> Webrev: http://cr.openjdk.java.net/~akulyakh/8147447/index.html
>>>>
>>>> The test WaitNotifyThreadTest.java tries expects to find in the 
>>>> jstack output the string similar to:
>>>> 'waiting on <0x000000008f64e6d0> (a java.lang.Object)'
>>>> However, with the -Xcomp option turned on there is no object 
>>>> reference available and the same strings look like:
>>>> 'waiting on <no object reference available>'
>>>> This causes the false failures of the test when executed with the 
>>>> -Xcomp option.
>>>>
>>>> We are modifying the test so it takes into account the possible 
>>>> difference between the jstack outputs.
>>>>
>>>> The same issue has been present in the legacy test from which this 
>>>> test has been ported, so it is not a new and not a regression issue.
>>>>
>>>> Best regards,
>>>> Alexander
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/serviceability-dev/attachments/20160121/a5f87e99/attachment.html>