BTW, I am curious, is it OK for TI when a method is compiled several times
and put on different addrs?
Yes, it's ok. All compiled forms of the method must be reported. Moreover when compiled form of the method is unloaded from memory it must be reported with Compiled Method Unload event. We should to think about this also. It seems to me that most natural way to implement CMU event is to iterate over all methods of class being unloaded and all theirs inlined methods. The similar problem is with GenerateEvents function ( http://java.sun.com/j2se/1.5.0/docs/guide/jvmti/jvmti.html#GenerateEvents). It should report all already compiled methods at any the time, on agent's request. It can be done also by iterating over all loaded class -> their methods -> their inlined methods. What do you think? Thanks, Eugene. On 10 Nov 2006 18:48:43 +0600, Egor Pasko <[EMAIL PROTECTED]> wrote:
On the 0x21D day of Apache Harmony Eugene Ostrovsky wrote: > Hello All. > > One more "hole" in current JVMTI Profiling implementation is Compiled Method > Load event. > > Current VM doesn't report this event for methods that are inlined by JIT. > Though spec requires it to be sent for every compiled method: > http://java.sun.com/j2se/1.5.0/docs/guide/jvmti/jvmti.html#CompiledMethodLoad > > To support the feature VM need to know about those inlined methods. Right > now I can see two possible approaches: > > 1. When VM initiates method compilation, it can ask the jit about methods > that were inlined to compiled method and report all of them. > 2. JIT itself can notify VM about every compiled method by calling some > special interface function after the method compilation. > > I'm not sure about which approach is better. > Each of them requires additional interface function (1.- to JIT from VM; 2. > - from VM to JIT). > > The second approach seems to be more complicated in terms of VM - JIT > interaction. I mean that the following scheme "VM calls JIT's function to > compile method. -> JIT's function in it's turn calls VM's function to notify > about compiled methods. -> VM's function dispatches the event to TI > agents..." introduces additional level of complexity than if "VM calls JIT's > function to compile method. VM asks JIT about inlined methods. VM dispatches > event to TI agents." Correct me if I am wrong, I see the picture as: (1): 1.1. VM -call-> JIT (compile a method for me, please) 1.2. VM -call-> JIT (gimme the list of addresses/functions) 1.3. VM -call-> JIT (please, free your resources allocated for these addrs) (2): 2.1. VM -call-> JIT (compile a method for me, please) 2.2. JIT -call-> VM (I generated code from addr X to addr Y, look at this one) 2.3. VM -call-> TI (here is the code for you) (1) has a disadvantage in case one JIT instance compiles different methods in parallel. And we should have a synchronized method addr repository, which is not easy to wipe out in the right way. (2) seems more straightforward from the JIT side because JIT can report method boundary addresses as soon as it determines them on emitting. That simplifies JIT impl (no allocating/freeng/synch). BTW, I am curious, is it OK for TI when a method is compiled several times and put on different addrs? > Ideas & suggestions are welcome. > > Thanks, > Eugene. > > On 10/24/06, Eugene Ostrovsky <[EMAIL PROTECTED]> wrote: > > > > Hi all. > > > > It seems that we have most of JVMTI implemented in drlvm. Still some of > > profiling support features is left. > > I'm going to take a look on "VM Object Allocation" event. > > I'll try to come up with design tomorrow. > > > > Thanks, > > Eugene. > > > > -- Egor Pasko
