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 Wed, 15 Nov 2006 15:48:53 GMT
Do I understand correctly that per-call-inline-info is a list of inline
chains for every call instruction offset within a code chunk?

If so, think we may replace per-call-inline-info with
per-region-inline-info. Why can't we use per-region-inline-info for stack
tracing.

The other question is: which component should collect and process
inline-info?
The current approach is that JIT collects the data and provides interface
for VM to extract useful information from it.
The other possible approach could be in using JIT to VM notifications about
compiled method (as George proposed). VM can store the inline info by itself
and process it on demand without disturbing JIT.

What do you think about these proposals?


On 10 Nov 2006 20:27:45 +0600, Egor Pasko <egor.pasko@gmail.com> wrote:
>
> On the 0x21D day of Apache Harmony Eugene Ostrovsky wrote:
> > >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.
>
> yes, sure, so we need to store the inlining data from JIT until unloading
>
> > 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?
>
> The question is where to store this info. AFAIK, there is a special
> CodeChunkInfo->_jit_info_block which is OK for that. Some info is
> stored there already, i. e. mapping of call instructions into "inline
> chain" they are in (so called per-call-inline-info). That's for
> precise stack traces (which is a necessity).
>
> Here we have a "region"-inline-info. Which is for TI. We can store it
> in the CodeChunkInfo->_jit_info_block, but, unfortunately, it is not
> typed, and is just a memory block. JIT is responsible for
> serializing/deserializing to/from it. What I am dreaming of is a
> tagged _jit_info_block. So "jit info" be a list of mem blocks, each
> marked with it's tag, so appropriate info can be found more naturally
> (not deserializing all big code block)
>
> Do you have alternative proposals where to store region-inline-info?
>
> There is one more issue, of course. Why not we unify both inline-infos
> (per-call and region-based)? IMHO, region-based inline-info is less
> precise (because of possible code motion in JIT), TI would not suffer
> much of this (I hope), but precise stack traces can suffer. So, I am
> for leaving both approaches as-is for now.
>
> It is also interesting how much memory would, for example, Eclipse eat
> for region-based inline-info and for per-call-inline-info when
> started? I cannot predict what is more compact.
>
> > 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
> > >
> > >
>
> --
> Egor Pasko
>
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message