Mailing-List: contact harmony-dev-help@incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: harmony-dev@incubator.apache.org
Received-SPF: pass (herse.apache.org: domain of gcjhd-harmony-dev@m.gmane.org
 designates 80.91.229.2 as permitted sender)
To: harmony-dev@incubator.apache.org
From: Egor Pasko <egor.pasko@gmail.com>
Subject: Re: [drlvm][jvmti] Profiling support - Compiled Method Load event
Date: 16 Nov 2006 13:41:02 +0600
Lines: 224
Message-ID: <ulkmbyh2p.fsf@gmail.com>
References: <1e3228450611100406n1d0ea58fp2c778fb9a3c49458@mail.gmail.com>
 <u64dn31sk.fsf@gmail.com>
 <1e3228450611100548p1ad336a4h23970a973cef307f@mail.gmail.com>
 <umz6z1in2.fsf@gmail.com>
 <1e3228450611150748t34fe79eej77f9c913b515a368@mail.gmail.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.3
Sender: news <news@sea.gmane.org>

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