On 5/24/16 6:03 PM, serguei.spit...@oracle.com wrote:
On 5/24/16 16:23, Daniel D. Daugherty wrote:
> Testing:
> Altered the nsk.jvmti co-located test
nsk/jvmti/ClassFileLoadHook/classfloadhk002
> to enable the can_generate_early_class_hook_events and checked
that new CFLH events
> are posted in the primordial phase and also they are not posted
otherwise.
Sorry for looping back on this...
I've been re-reading this thread off and on for a while now...
I'm okay with this part of the testing statement:
> checked that new CFLH events are posted in the primordial phase
but this part bothers me:
> and also they are not posted otherwise
I'm not sure what that last part means exactly. I think it might
be saying that there are certain CFLH events that the test expects
to be posted in the primordial phase and the test verifies that
those CFLH events are posted in the primordial phase and not in
the next phase (the start phase). I'm hoping that the testable
assertion is more clear than the above text.
Dan, sorry that my statement above is not clear.
The 'otherwise' means the same test but unaltered.
Unaltered test does not enable new capability and so, the CFLH events
should not be posted in the primordial phase.
Got it. I'm good with a test to verify that the older JVM/TI
behavior works as expected along with a test for the newer
behavior.
One other possible issue: if the primordial phase is still
single threaded, then there is no race between a thread doing
this early class loading (and posting of the CFLH events) and
the thread that is changing the JVM/TI phase from "primordial
phase" to "start phase". However, if the primordial phase is
now multi-threaded, then there might be a race between the
thread posting the CFLH event and JVM/TI phase switch...
This is interesting observation, thanks.
Why do you think the primordial thread is multi-threaded now?
I haven't been paying close attention to Jigsaw so I'm not sure
if primordial phase is multi-threaded or not...
We have this kind of race problem in general, especially
with the JVM/TI phase switch to the DEAD phase.
The phase can be switched even in the middle of the event post.
I'm currently looking at several bugs related to
JVMTI_ERROR_WRONG_PHASE(112).
This problem needs a good solution, at least to make the nightly
testing stable.
Yes, I'm well aware of that problem. I believe I've made a number
of comments on various JVMTI_ERROR_WRONG_PHASE bugs over the years.
It's going to need some sort of handshake to solve it. Much like
the suspend/resume dance that we do on thread exit...
We'll have to brainstorm on how to make things more robust...
Dan
Thanks,
Serguei
Dan
On 4/14/16 2:24 AM, serguei.spit...@oracle.com wrote:
Please, review the Jigsaw-related fix for:
https://bugs.openjdk.java.net/browse/JDK-8153749
Hotspot webrev:
http://cr.openjdk.java.net/~sspitsyn/webrevs/2016/hotspot/8153749-Jigsaw-newcap.hs1/
Jdk webrev:
http://cr.openjdk.java.net/~sspitsyn/webrevs/2016/jdk/8153749-Jigsaw-newcap.jdk1/
Summary:
This is a Jigsaw related enhancement.
Some agents need to get a CFLH event for classes loaded in the
primordial phase.
This is not possible in JDK 9 because existing agents may
instrument code in the
primordial or start phase before the module system has completed
initialization.
We introduce a new capability: can_generate_early_class_hook_events.
If this capability and can_generate_all_class_hook_events are
enabled then
the CFLH event could be posted for classes loaded in the
primordial phase.
We leave can_generate_early_vmstart as is, no changes.
This enhancement needs a CCC request filed.
I will file it once the JVMTI spec changes are reviewed.
Testing:
Altered the nsk.jvmti co-located test
nsk/jvmti/ClassFileLoadHook/classfloadhk002
to enable the can_generate_early_class_hook_events and checked
that new CFLH events
are posted in the primordial phase and also they are not posted
otherwise.
Thanks,
Serguei
