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 Mon, 18 Dec 2006 13:48:54 GMT
Great.
That's what I was dreaming of. :)

There's one more issue related to HARMONY-2769 subject.
I guess that inlined method code region may be equal to it's caller method
region.
E.g. method a() is called from method b() which does nothing except calling
a(). b() in it's turn is called from method c().
Method a() could be inlined to b(), and b() could be inlined to c().
Thus code regions for a() and b() are the same, since b() has no it's own
instructions but only those inlined from a().
In this case VM using only region information couldn't determine which of
a() and b() is caller and which is callee.
It seems that to solve this problem we need JIT to report for the method not
the most outer method in inline chain (as it does in
H-2145-JIT-side.patch<http://issues.apache.org/jira/secure/attachment/12345590/H-2145-JIT-side.patch>)
but the first-hand caller method.
Is it possible for JIT?

On 18 Dec 2006 18:09:45 +0600, Egor Pasko <egor.pasko@gmail.com> wrote:
>
> FYI:
> Just to track things right I filed a new JIRA with proposal to
> InlineInfo unification:
>
> HARMONY-2769 [drlvm][jit] use per-region InlineInfo from global
> storage in VM to report stack frames of inlined methods
>
> depends on HARMONY-2145, as expected. Feel free to vote :)
>
> On the 0x223 day of Apache Harmony Egor Pasko wrote:
> > On the 0x222 day of Apache Harmony Eugene Ostrovsky wrote:
> > > Do I understand correctly that per-call-inline-info is a list of
> inline
> > > chains for every call instruction offset within a code chunk?
> >
> > yes
> >
> > > 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.
> >
> > Relying on per-region-inline-info introduces some constraints for JIT
> > design. Specifically, it becomes not easy to move instruction regions
> > across method boundaries.
> >
> > On the other hand, we do not move calls today (and I doubt we will
> > since it is easier to inline than prove that side effects allows
> > swapping two calls). JIT guys, comment here if you have other opinions!
> >
> > So, frankly, I do not see any strong reasons to stick with
> > per-call-inline-info. The reasons to use them might be:
> > * less memory consuming than region-based (that's an open question,
> >   though), in non-JVMTI mode we can fall down to call-based with
> >   region-based=OFF
> > * more precise (JIT mechanisms guarantee that this info won't be lost)
> >
> > Although, there is a disadvantage of per-call-inline-info:
> > * we cannot afford reporting stack frames on exceptions (because there
> >   are a lot fo potentially exceptional instructions and storing inline
> >   chains for all of them would be ineffective) see HARMONY-2114
> >
> > > 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.
> >
> > I like this idea! Just a reminder: in this approach VM should not forget
> to:
> > * free associated resources, when code chunks are freed
> > * keep the inline tree to report stack traces properly
> >
> > currently, you have all tools to implement this proposal on the VM
> > side. per-call-inline-info is used in st_print_stack(...) and in some
> > other tricky places. To completely eliminate per-call-inline-info you
> > will need to retarget those places at using per-region-inline-info.
> >
> > Anyway, it is worth a try. We can then measure how much space we saved
> > in JVMTI mode and in default mode. That would be interesting.
> >
> > > What do you think about these proposals?
> >
> > Using *one inline-info* approach is better than using two. So, I support
> > your unification proposal. AFAIR, Eclipse is sensitive to reporting
> > stack precisely, so, there is something to check the prototype on.
> >
> > > 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
> > > >
> > > >
> >
> > --
> > Egor Pasko
> >
> >
>
> --
> Egor Pasko
>
>

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