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

[serguei.spitsyn at oracle.com]

On 1/21/16 16:37, serguei.spitsyn at oracle.com wrote:
> 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.

I hope, it is always the case for the purpose the Alexander is going to 
use the isCompMode().

Thanks,
Serguei


>
> 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/d42ff623/attachment-0001.html>