Dear All,When writing an agent to profile a java program using jvmTI, our agentcode needs to implement handler methods(event callback methods) tohandle events that we asked the jvmTI environment to dispatch to ouragent. In the sample agent heapTracker.c in j2sdk demo folder, somecallback functions(specifically, cbVMInit,cbVMStart, cbVMDeath, cbException), before they do anything on thereceived event, they first entered a "raw monitor", while in all theother callback functions, they do not need to enter the " rawmonitor" .My questions are:1. What is a "raw monitor",  what does it do,how is it different froma "monitor"?2. Why we need to first enter the "raw monitor" for some particularevents?3.Any reference material on this topic out there on the web?Thanks in advanceeric

On 9 28 ,   5 08 , xuwend...@gmail.com wrote:> 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> ericWhat is Raw Monitor?Raw monitors are similar to Java monitors. The difference is that rawmonitors are not associated with Java objects.Why do we need it?Once you have set up the event callback, and enabled the events, thecallback functions will get called from the JVM. Keep in mind thatmost of these callback functions need to be completely MT-safe (somesuch as the JVMTI_EVENT_VM_INIT will only be called once per VMinitialization and you have a little flexibility knowing that it's theonly active thread), so that means access to any static or extern dataneeds to be carefully handled, and any native system functions alsoneed to be MT-safe. Ideally, all your C or C++ functions should bedesigned in a re-entrant style, and static or extern data should beavoided. The simplest approach to protecting static or global data (asseen in most of the JVMTI demos) is to create a single raw monitor inAgent_OnLoad or vmInit, and use that raw monitor in all the callbacksto assure that only one callback is active at any given point in time(creates a critical section in the native code). This is also theapproach that can create performance bottlenecks in the applicationusing the agent library, by preventing threads from executing at thesame time. Often times, a per-thread raw monitor, or multiple rawmonitors, will be a better performance solution, but may also become acorrectness issue with regards to deadlocks if you aren't careful onthe nesting orders when parts of the code need both raw monitors.