RFR: 8153749 - New capability can_generate_early_class_hook_events
Daniel D. Daugherty
daniel.daugherty at oracle.com
Wed May 25 00:24:59 UTC 2016
On 5/24/16 6:03 PM, serguei.spitsyn at oracle.com wrote:
> On 5/24/16 16:23, Daniel D. Daugherty wrote:
>> > Testing:
>> > Altered the nsk.jvmti co-located test
>> > 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
>> 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
>> 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
> 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...
>> On 4/14/16 2:24 AM, serguei.spitsyn at oracle.com wrote:
>>> Please, review the Jigsaw-related fix for:
>>> Hotspot webrev:
>>> Jdk webrev:
>>> 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
>>> 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.
>>> Altered the nsk.jvmti co-located test
>>> 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
More information about the hotspot-dev