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 Mon, 18 Dec 2006 12:09:45 GMT
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
View raw message