Mailing-List: contact dev-help@harmony.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@harmony.apache.org
Received-SPF: pass (herse.apache.org: domain of eugene.s.ostrovsky@gmail.com
 designates 64.233.182.189 as permitted sender)
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws;
        s=beta; d=gmail.com;
        h=received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:references;
        b=CHCl9dSRhNCsxvt+iAXumH3fsk4tkeVbq4qwT3Is5lKLH8FsooOzF1yvcH3mj1yJJCvcOcoqtC5dhvcn0UEfbjG3zT5qaGvkUFcoYc6sp1uaTFS3QIa9wk/SxtiS7xH0STl3uecWD5X9y2bAHAf9JwvLu+KaFbnkhQq2iA+WKMc=
Message-ID: <1e3228450612180201j63c2f3d1g1f1415ca75897f63@mail.gmail.com>
Date: Mon, 18 Dec 2006 13:01:36 +0300
From: "Eugene Ostrovsky" <eugene.s.ostrovsky@gmail.com>
To: dev@harmony.apache.org
Subject: Re: [drlvm][jvmti] Profiling support - Compiled Method Load event
In-Reply-To: <u4prxcp4p.fsf@gmail.com>
MIME-Version: 1.0
Content-Type: multipart/alternative;
	boundary="----=_Part_11679_16198033.1166436096269"
References: <1e3228450611100406n1d0ea58fp2c778fb9a3c49458@mail.gmail.com>
	 <uwt53iwwa.fsf@gmail.com> <elijq3$mes$1@sea.gmane.org>
	 <uirgifqeb.fsf@gmail.com> <elogvi$5g5$2@sea.gmane.org>
	 <uzm9scce1.fsf@gmail.com>
	 <1e3228450612140020o10ee11b9kf68f00032467645f@mail.gmail.com>
	 <ulkladbs6.fsf@gmail.com>
	 <1e3228450612150319i72f378e9wd3132804842d0613@mail.gmail.com>
	 <u4prxcp4p.fsf@gmail.com>

------=_Part_11679_16198033.1166436096269
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

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
>
>

------=_Part_11679_16198033.1166436096269--