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

[Rickard Bäckman]

Thank you Dan and Karen!

/R

12 apr 2012 kl. 21.48 skrev "Daniel D. Daugherty" <daniel.daugherty at oracle.com 
 >:

> 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 ...
>>