On 1/21/16 16:37, serguei.spit...@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.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.
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.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
