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

[Daniel D. Daugherty]

Based on some off-thread discussions, the TRACE_START() call does not
have to happen before the VMInit event is posted so I'm happy with
the code change.

Dan

On 4/12/12 9:21 AM, Daniel D. Daugherty wrote:
> 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 ...
>