[prev in list] [next in list] [prev in thread] [next in thread] 

List:       openjdk-serviceability-dev
Subject:    Re: Setting JVMTI Capabilities when VM is in "Live Phase"
From:       David Holmes <david.holmes () oracle ! com>
Date:       2016-08-17 3:01:21
Message-ID: 352ff2e6-c8f4-cfe3-fa67-4e63387b6f80 () oracle ! com
[Download RAW message or body]

On 17/08/2016 6:57 AM, Leela Mohan wrote:
> Your thoughts on this will be helpful.
>
> Thanks,
> Leela
>
> [ Removed "serviceability-dev@openjdk.net" mailing alias added
> "hotspot-dev" since i am getting failed mail delivery notification ]

Added back - it is openjdk.java.net, not openjdk.net

David
-----

> On Fri, Aug 12, 2016 at 4:33 PM, Daniel D. Daugherty <
> daniel.daugherty@oracle.com> wrote:
>
>> On 8/12/16 5:27 PM, Leela Mohan wrote:
>>
>> Hi Daniel,
>>
>> Actually,  I was thinking about the case where compiler choose not to have
>> complete "de-opt" state. For ex: Local pruning. I can also think of other
>> cases which need callback events like, posting exceptions to the agent.
>>
>> JVMTI requests for examining/changing the stack frame would conservatively
>> de-optimize the compile methods but not all de-optimizable locations can
>> restore the java state user expect.
>>
>> What are the expectations for VM for these cases ?
>>
>>
>> I think we'll have to wait for someone more current in how the compilers
>> interact with JVM/TI to chime in here. I stopped actively working on
>> JVM/TI back in 2010 or so... :-)
>>
>> Dan
>>
>>
>>
>> Thanks,
>> Leela
>>
>> On Fri, Aug 12, 2016 at 4:04 PM, Daniel D. Daugherty <
>> daniel.daugherty@oracle.com> wrote:
>>
>>> On 8/12/16 4:21 PM, Leela Mohan wrote:
>>>
>>>> Hi experts,
>>>>
>>>> It looks like, we don't disallow setting capabilities when VM is in
>>>> "JVMTI_PHASE_LIVE". And, I notice, for every new compilation of method,
>>>> ciEnv caches the JVMTI state and expects those assumptions to be true
>>>> during the compilation. Otherwise, dump the compiled method.
>>>>
>>>> However, we don't seem to do anything with the methods which were
>>>> compiled
>>>> before setting the capability.
>>>>
>>>> What is the understanding?
>>>>
>>>> Thanks,
>>>> Leela
>>>>
>>>
>>> Hi Leela,
>>>
>>> I'm guessing that you are talking about this capability:
>>>
>>> http://docs.oracle.com/javase/8/docs/platform/jvmti/jvmti.ht
>>> ml#jvmtiCapabilities.can_generate_compiled_method_load_events
>>>
>>> and this event:
>>>
>>> http://docs.oracle.com/javase/8/docs/platform/jvmti/jvmti.ht
>>> ml#CompiledMethodLoad
>>>
>>>
>>> The can_generate_compiled_method_load_events capability needs to be added
>>> in order to generate CompiledMethodLoad events. Capabilities are added via
>>> http://docs.oracle.com/javase/8/docs/platform/jvmti/jvmti.ht
>>> ml#AddCapabilities
>>> which can be called from different JVM/TI phases. Different VM
>>> implementations
>>> can require that certain capabilities can only be added in certain JVM/TI
>>> phases.
>>> However, if AddCapabilities() does not return a JVM/TI error when a
>>> capability
>>> is added in a phase, e.g., the live phase, then you can safely assume that
>>> the capability has been added.
>>>
>>>
>>> In your example, it sounds like the capability is added in the live phase
>>> because you are seeing events generated for newly compiled methods. In
>>> order
>>> to see synthetic events for methods that were compiled before you added
>>> the
>>> capability, your agent needs to use a different function:
>>>
>>> http://docs.oracle.com/javase/8/docs/platform/jvmti/jvmti.ht
>>> ml#GenerateEvents
>>>
>>> The documentation for Compiled Method Load has this line:
>>>
>>>> These events can be sent after their initial occurrence with
>>> GenerateEvents.
>>>
>>> and that sounds just like your situation.
>>>
>>> Hope this helps.
>>>
>>> Dan
>>>
>>>
>>
>>
[prev in list] [next in list] [prev in thread] [next in thread]