jvmTI raw monitor

[xuwenduan]

Dear All,

When writing an agent to profile a java program using jvmTI, our agent
code needs to implement handler methods(event callback methods) to
handle events that we asked the jvmTI environment to dispatch to our
agent. In the sample agent heapTracker.c in j2sdk demo folder, some
callback functions(specifically, cbVMInit,
cbVMStart, cbVMDeath, cbException), before they do anything on the
received event, they first entered a "raw monitor", while in all the
other callback functions, they do not need to enter the " raw
monitor" .

My questions are:
1. What is a "raw monitor", what does it do,how is it different from
a "monitor"?

2. Why we need to first enter the "raw monitor" for some particular
events?


3.Any reference material on this topic out there on the web?


Thanks in advance
eric

 

[siweheee]

Dear All,

When writing an agent to profile a java program using jvmTI, our agent
code needs to implement handler methods(event callback methods) to
handle events that we asked the jvmTI environment to dispatch to our
agent. In the sample agent heapTracker.c in j2sdk demo folder, some
callback functions(specifically, cbVMInit,
cbVMStart, cbVMDeath, cbException), before they do anything on the
received event, they first entered a "raw monitor", while in all the
other callback functions, they do not need to enter the " raw
monitor" .

My questions are:
1. What is a "raw monitor", what does it do,how is it different from
a "monitor"?

2. Why we need to first enter the "raw monitor" for some particular
events?

3.Any reference material on this topic out there on the web?

Thanks in advance
eric

What is Raw Monitor?

Raw monitors are similar to Java monitors. The difference is that raw
monitors are not associated with Java objects.

Why do we need it?

Once you have set up the event callback, and enabled the events, the
callback functions will get called from the JVM. Keep in mind that
most of these callback functions need to be completely MT-safe (some
such as the JVMTI_EVENT_VM_INIT will only be called once per VM
initialization and you have a little flexibility knowing that it's the
only active thread), so that means access to any static or extern data
needs to be carefully handled, and any native system functions also
need to be MT-safe. Ideally, all your C or C++ functions should be
designed in a re-entrant style, and static or extern data should be
avoided. The simplest approach to protecting static or global data (as
seen in most of the JVMTI demos) is to create a single raw monitor in
Agent_OnLoad or vmInit, and use that raw monitor in all the callbacks
to assure that only one callback is active at any given point in time
(creates a critical section in the native code). This is also the
approach that can create performance bottlenecks in the application
using the agent library, by preventing threads from executing at the
same time. Often times, a per-thread raw monitor, or multiple raw
monitors, will be a better performance solution, but may also become a
correctness issue with regards to deadlocks if you aren't careful on
the nesting orders when parts of the code need both raw monitors.