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.kulyakh...@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.lar...@oracle.com
To: alexander.kulyakh...@oracle.com
Cc: serviceability-dev@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.kulyakh...@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
