RFR: 7160924: jvmti: GetPhase returns incorrect phase before VMInit event is issued

[Daniel D. Daugherty]

I think we may have two problems here.

1) The TRACE_START() call has widened the window between
    the phase change and the VMInit event posting. Was
    there a good reason for calling TRACE_START() from
    that location? In other words, did it have to happen
    before VMInit was posted for some reason?

2) The parallel nature of the getphase001 test is going to
    lead to false failures of the particular test assertion.

See my comments in the bug report for a detailed analysis.

Dan


On 4/12/12 8:31 AM, Daniel D. Daugherty wrote:
> I want to take a closer look at the failing test...
>
> Be back soon...
>
> Dan
>
>
> On 4/12/12 8:03 AM, Karen Kinnear wrote:
>> Dmitry,
>>
>> I hear your point, there is a comment in the VM Initialization Event 
>> that "In the case of VM start-up
>> failure, this event will not be sent".
>>
>> That said, the goal of the VM initialization event is to inform the 
>> agent that it is free
>> to call any JNI or JMVTI function. Many agents want to be able to 
>> start tracking the VM as early as possible.
>>
>> So there is a trade-off in how early you send this event and risks of 
>> VM failures after we send it.
>> To maximize benefits to users of the API, the current trade-off is to 
>> declare the VM initialized, i.e. in live phase,
>> and to post the VM Initialization event  as soon as we meet the 
>> agents' needs.
>>
>> Yes, it is possible for the VM to exit later, both on additional 
>> subsystem startup operations and of course
>> due to things like out of memory errors at any time. So the 
>> "consistency" is that if we have a failure
>> in starting up the VM for the operations critical to jvmti agents, we 
>> exit without sending the event. For
>> failures later during startup and beyond, we don't. Bootstrapping is 
>> a very delicate process and
>> we want to optimize for the agents starting as early as they can for 
>> the success cases.
>>
>> While longer term we would like to improve our ability to recover 
>> from some of the memory errors,
>> I think the trade-off of empowering the agents to be functional as 
>> early as we can is the right balance
>> at this time.
>>
>> So - I would support the bug fix as is.
>>
>> thanks,
>> Karen
>>
>> On Apr 12, 2012, at 9:12 AM, Dmitry Samersoff wrote:
>>
>>> Rickard,
>>>
>>> As far as I understand the code, after your changes we will
>>> post JVMTI event
>>>
>>> JvmtiExport::post_vm_initialized();
>>>
>>> ever if later JVM aborts on some error.
>>>
>>> I'm not sure it's a good idea because in couple of other
>>> places we abort VM without sending the event, so
>>> behavior of agent become inconsistent.
>>>
>>> -Dmitry
>>>
>>>
>>>
>>> On 2012-04-12 16:12, Rickard Bäckman wrote:
>>>> Hi,
>>>>
>>>> can I get review for this small change? The issue is that if we are
>>>> running tracing startup code inbetween setting the phase to
>>>> JVMTI_PHASE_LIVE and posting the VMInit event.
>>>>
>>>> Webrev:
>>>> http://cr.openjdk.java.net/~rbackman/7160924/webrev/
>>>>
>>>> CR: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7160924
>>>>
>>>> Thanks
>>>> /R
>>>
>>> -- 
>>> Dmitry Samersoff
>>> Java Hotspot development team, SPB04
>>> * There will come soft rains ...