Setting JVMTI Capabilities when VM is in "Live Phase"
leelamohan.venati at gmail.com
Fri Aug 12 23:27:05 UTC 2016
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 ?
On Fri, Aug 12, 2016 at 4:04 PM, Daniel D. Daugherty <
daniel.daugherty at 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?
> Hi Leela,
> I'm guessing that you are talking about this capability:
> and this event:
> The can_generate_compiled_method_load_events capability needs to be added
> in order to generate CompiledMethodLoad events. Capabilities are added via
> which can be called from different JVM/TI phases. Different VM
> can require that certain capabilities can only be added in certain JVM/TI
> However, if AddCapabilities() does not return a JVM/TI error when a
> 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
> to see synthetic events for methods that were compiled before you added the
> capability, your agent needs to use a different function:
> The documentation for Compiled Method Load has this line:
> > These events can be sent after their initial occurrence with
> and that sounds just like your situation.
> Hope this helps.
More information about the hotspot-runtime-dev