harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Eugene Ostrovsky" <eugene.s.ostrov...@gmail.com>
Subject Re: [drlvm][jvmti] Profiling support - Compiled Method Load event
Date Fri, 10 Nov 2006 13:48:01 GMT
>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 <egor.pasko@gmail.com> 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 <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
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message