harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Egor Pasko <egor.pa...@gmail.com>
Subject Re: [drlvm][jvmti] Profiling support - Compiled Method Load event
Date Fri, 10 Nov 2006 12:48:43 GMT
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 <eugene.s.ostrovsky@gmail.com> 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


Mime
View raw message