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 Thu, 21 Dec 2006 10:13:34 GMT
On the 0x245 day of Apache Harmony Ivan Popov wrote:
> Since DRLVM seems the unique JVM implementation that reports inlined
> methods, it was proposed to document the order in which inlined
> methods are reported with COMPILED_METHOD_LOAD events - from the most
> wrapping method to the most inlined ones or vise versa. This will
> allow to adjust JVMTI tools for handling inlined methods correctly.

good idea!

> Thanks.
> Ivan
> 
> On 12/18/06, Eugene Ostrovsky <eugene.s.ostrovsky@gmail.com> wrote:
> > Let me propose the following design:
> >
> > Compiled method load event. More precise specification for inlined methods.
> > 1. CML event must be sent for every method compiled by JIT.
> > If compiled method code is disposed in several disconnected regions each of
> > them must be reported by separate CML event.
> > Each region location is described by code_addr and code_size parameters.
> > Native addresses to bytecode location correspondence should be described in
> > map parameter if this information is available. If compiled method code
> > contains code blocks of inlined methods the addresses of those blocks should
> > be associated with the location of corresponding invoke bytecode
> > instruction.
> > 2. If compiled method code region was inlined within the code region of the
> > outer method it should be reported by separate CML event. Inlined method
> > code region must be enclosed within one of the outer method's code regions.
> > I.e. outer.start <= inlined.start < inlined.end <= outer.end (where
> > method.start = code_addr , method.end = code_addr + code_size - 1)
> > 3. According to #1 and #2 any two of reported regions (R1, R2) may by
> > enclosed one by other (in case of inlining) but must not overlap (i.e.
> > R1.start < R2.start <= R1.end < R2.end condition must not be true).
> >
> > Is it clear enough?
> > What do you think?
> >
> > On 15 Dec 2006 18:36:22 +0600, Egor Pasko <egor.pasko@gmail.com> wrote:
> > >
> > > On the 0x240 day of Apache Harmony Eugene Ostrovsky wrote:
> > > > I experimented with sun and bea vms.
> > >
> > > did you try HotSpot for JSE 6 (with attach anytime feature)?
> > >
> > > > None of them report inlined methods.
> > > >
> > > > Thus we need to make a decision by ourselves.
> > >
> > > :) yes
> > >
> > > > On 14 Dec 2006 16:14:49 +0600, Egor Pasko <egor.pasko@gmail.com>
wrote:
> > > > >
> > > > > On the 0x23F day of Apache Harmony Eugene Ostrovsky wrote:
> > > > > > I'll try to make test to investigate RI behavior.
> > > > >
> > > > > thank you thank you thank you
> > > > >
> > > > > > On 13 Dec 2006 16:34:46 +0600, Egor Pasko <egor.pasko@gmail.com>
> > > wrote:
> > > > > > >
> > > > > > > On the 0x23E day of Apache Harmony George Timoshenko wrote:
> > > > > > > > Egor,
> > > > > > > >
> > > > > > > > thanks for clear scheme.
> > > > > > > >
> > > > > > > > In your terms I'd do something like this:
> > > > > > > >
> > > > > > > > * firstly - raise event for X:
> > > > > > > >      CompiledMethodLoad(start=X.1.start,
> > > > > > > >                         method_size=X.1.size + X.2.size,
> > > > > > > >                         addr_loc_map=
> > > > > > > >                         [X.1.start -> bcoff1,
> > > > > > > >                          X.2.start -> bcoff2])
> > > > > > > >    * secondly - raise event for Y:
> > > > > > > >      CompiledMethodLoad(start=Y.1.start,
> > > > > > > >                         method_size=Y.1.size,
> > > > > > > >                         addr_loc_map=
> > > > > > > >                         [Y.1.start -> bcoff_Y])
> > > > > > >
> > > > > > > good question!
> > > > > > >
> > > > > > > IMHO, code_addr and code_size outlines a region where method
code
> > > is
> > > > > > > contained. In that case VM can quickly tell which method
the IP
> > > > > > > (instruction pointer) belongs to. So, I intentionally suggested
> > > > > > > code_size=(X.1.size + Y.1.size + X.2.size) instead of (X.1.size
+
> > > > > > > X.2.size).
> > > > > > >
> > > > > > > BTW, Eugene, do you have some important observations of
the RI
> > > > > > > behaviour for us?
> > > > > > >
> > > > > > > >  >   For example, we have
> > > > > > > >  >   some chinks of methods X and Y intermixed
like this:
> > > > > > > >  >   "X.1,Y.1,X.2". To overcome we may:
> > > > > > > >  >   * raise a single event for X:
> > > > > > > >  >     CompiledMethodLoad(start=X.1.start,
> > > > > > > >  >                        method_size=X.1.size
+ Y.1.size +
> > > X.2.size
> > > > > ,
> > > > > > > >  >                        addr_loc_map=
> > > > > > > >  >                        [X.1.start -> bcoff1,
> > > > > > > >  >                         Y.1.start -> 0,
> > > > > > > >  >                         X.2.start -> bcoff2])
> > > > > > > >  >   * raise 2 events for X:
> > > > > > > >  >     CompiledMethodLoad(start=X.1.start,
> > > > > > > >  >                        method_size=X.1.size,
> > > > > > > >  >                        addr_loc_map=
> > > > > > > >  >                        [X.1.start -> bcoff1])
> > > > > > > >  >     CompiledMethodLoad(start=X.2.start,
> > > > > > > >  >                        method_size=X.2.size,
> > > > > > > >  >                        addr_loc_map=
> > > > > > > >  >                        [X.2.start -> bcoff2])
> > > > > > > >  >
> > > > > > > >  > I would highly appreciate if some JVMTI guru
steps down from
> > > > > Olymp
> > > > > > > and
> > > > > > > >  > tells which of two is the best, or at least
says what RI does
> > > in
> > > > > that
> > > > > > > >  > case (or, maybe, RI does not generate non-contigous
blocks?)
> > > > > > > >  >
> > > > > > > >  > I like the second approach (raise 2 events)
> > > > > > > >  >
> > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > > > --
> > > > > > > Egor Pasko
> > > > > > >
> > > > > > >
> > > > >
> > > > > --
> > > > > Egor Pasko
> > > > >
> > > > >
> > >
> > > --
> > > Egor Pasko
> > >
> > >
> >
> >
> 

-- 
Egor Pasko


Mime
View raw message