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 ivan.g.popov@gmail.com
 designates 72.14.214.239 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:content-transfer-encoding:content-disposition:references;
        b=aTiH8VDUHbLJcwEpLU4pFKsAvM9uvxL2ecYqPTMk3p/7lpTkyd7TX7in7ZwUlX79pvNBvQe2cDCqw7yrAXRBgKP/s5VHGlQQICXLloUhXC8MOL+gTFLaPFTi+n2QASRCuNG4kYsyf2R4jFOj94vKnW+81LdT99KOz2WUjjqrarE=
Message-ID: <b6cb498e0612120455y575a02b2x3f06f0e9cdc9298d@mail.gmail.com>
Date: Tue, 12 Dec 2006 18:55:08 +0600
From: "Ivan Popov" <ivan.g.popov@gmail.com>
To: dev@harmony.apache.org
Subject: Re: [drlvm][jvmti] Profiling support - Compiled Method Load event
In-Reply-To: <b6cb498e0612110831l383304bbifff8243fb64874ae@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
References: <1e3228450611100406n1d0ea58fp2c778fb9a3c49458@mail.gmail.com>
	 <u4psalu38.fsf@gmail.com> <el3ab6$ja7$1@sea.gmane.org>
	 <uvekqk6ua.fsf@gmail.com> <el68al$6v1$1@sea.gmane.org>
	 <uwt53iwwa.fsf@gmail.com> <elijq3$mes$1@sea.gmane.org>
	 <1e3228450612110350y19414087k8304a83b3388b454@mail.gmail.com>
	 <uejr6fpb3.fsf@gmail.com>
	 <b6cb498e0612110831l383304bbifff8243fb64874ae@mail.gmail.com>

I had a talk with Java profiler developers about problems with
reporting inlined methods. The answer was that the current JVMTI specs
are unclear in this area and different vendors may interpret them
differently. However, it would be better if CompiledMethodLoad reports
the whole code of the method, but not separate chunks. This would
facilitate post processing analysis.

So the suggested solution for this problem is different:

1. Report all code for a method including all inlined code from other
methods as a continuous range in one CompiledMethodLoad event

2. Report code of each inlined method in a separate events.

With this approach location of a native instruction can be mapped to
several methods concurrently. It is up to JVMTI tool how to interpret
this multiple mapping and show it to end user. Simple tools may map
native locations to the first found method, while advanced tools may
handle it differently and provide end user with more detailed data
about inlined methods.

Thanks.
Ivan

On 12/11/06, Ivan Popov <ivan.g.popov@gmail.com> wrote:
> I think the approach with reporting each chunk of a method code in a
> separate event solves most problems, though this interpretation of
> CompiledMethodLoad event may look strange. However, as JVMTI spec
> allows several compiled instances of the same method to be presented
> at the same time, this should not break existing JVMTI tools like Java
> profilers.
>
> I'm going to discuss this with developers of a Java profiler and write
> here if there are some hidden problems with this approach.
>
> Thanks.
> Ivan
>
> On 11 Dec 2006 21:02:56 +0600, Egor Pasko <egor.pasko@gmail.com> wrote:
> > On the 0x23C day of Apache Harmony Eugene Ostrovsky wrote:
> > > Guys,
> > >
> > > As far as I understand,
> > >
> > > 1. it is not actually a REQUIREMENT of JVMTI spec.
> > > Spec says that "jvmtiAddrLocationMap* map" parameter could be "...NULL if
> > > mapping information cannot be supplied...".
> > > I.e. spec allows VM not to provide native address to location mapping if it
> > > isn't available.
> > >
> > > 2. Spec says that each entry of the map specifies "... The native address
> > > range of each entry is from start_address  to start_address-1 of the next
> > > entry...". Thus we can't report non continuous code blocks using this data
> > > structure.
> > >
> > > 3. I've made an experiment with RI VM. Here's an example of the log:
> > > ------------
> > > CompiledMethodLoad:
> > >     method:    charAt (I)C
> > >     class:    Ljava/lang/String;
> > >     code_size:    195
> > >     code_addr:    00B43767
> > >     map_length:    8
> > >     map:
> > >         start_address:    00B437E0    location:    17
> > >         start_address:    00B437E3    location:    20
> > >         start_address:    00B437E9    location:    20
> > >         start_address:    00B437FB    location:    31
> > >         start_address:    00B43802    location:    31
> > >         start_address:    00B4380F    location:    12
> > >         start_address:    00B4381B    location:    12
> > >         start_address:    00B43825    location:    17
> > > ------------
> >
> > nice! thank you! So, the location might be the same for several start
> > addresses.
> >
> > > As you can see map doesn't provide location info for the addresses in the
> > > beginning of the code block [0x00B43767, 0x00B437E0) and in the end of the
> > > code block (0x00B43825, 0x00B43767 + 195)
> > >
> > > In my opinion, it is reasonable to report compiled method load event for
> > > continuous blocks of code separately.
> >
> > Yes, I like that too. If we are in N non-contiguous code chunks,
> > raise N events of CompileMethodLoad. George, what do you think?
> >
> > > On 12/11/06, George Timoshenko <george.timoshenko@gmail.com> wrote:
> > > >
> > > > Egor Pasko wrote:
> > > > > On the 0x237 day of Apache Harmony George Timoshenko wrote:
> > > > >> Egor Pasko wrote:
> > > > >>> On the 0x236 day of Apache Harmony George Timoshenko wrote:
> > > > >>>> Egor Pasko wrote:
> > > > >>>>> On the 0x235 day of Apache Harmony George Timoshenko wrote:
> > > > >>>>>> Eugene,
> > > > >>>>>>
> > > > >>>>>> I've answered in JIRA:
> > > > >>>>>>
> > > > >>>>>> https://issues.apache.org/jira/browse/HARMONY-2145#action_12455313
> > > > >>>>>>
> > > > >>>>>> (Summary: Everything is OK)
> > > > >>>>>>
> > > > >>>>>> For this particular testcase it is possible. But there is a general
> > > > >>>>>> problem:
> > > > >>>>>>
> > > > >>>>>> Code layout may be quite unordered. (It mostly depends on hottness,
> > > > >>>>>> not the instructions<->method relations) So a method (say A) body
> > > > >>>>>> can be layouted at two (or more) unsuccessive regions.  And the
> > > > >>>>>> regeion between them can belong to some another method (say B). And
> > > > >>>>>> B is _not_ inlined into A.
> > > > >>>>> That is essential, an inlined method can be separated in
> > > > >>>>> non-contiguous regions for performance during CFG alignment. IMHO,
> > > > we
> > > > >>>>> should register several code blocks for the same inlined method (if
> > > > >>>>> the method's code was split into parts) through the
> > > > >>>>> compiled_method_load(...) interface. This can be done completely on
> > > > >>>>> the JIT side.
> > > > >>>>> What do you, guys, think?
> > > > >>>> No doubts it can be done on the JIT side, but what is the purpose of
> > > > it?
> > > > >>>>
> > > > >>>> If there is only one question: "I get instruction, which method does
> > > > >>>> it belong to?" it can be answerd easily:
> > > > >>>>
> > > > >>>> For each method jvmtiAddrLocationMap is reported. And each
> > > > instruction
> > > > >>>> (with particular codeAddress) belongs to the only one such map.
> > > > >>>>
> > > > >>>> I do not understand the necessity of reporting each piece (a number
> > > > of
> > > > >>>> instructions that goes in a row and belongs to the same method) of a
> > > > >>>> method while we are already reporting _each_instruction_ separately.
> > > > >>> 1. is reporting _each_instruction_ effective?
> > > > >> It is a Spec. requirement.
> > > > >
> > > > > could you point the exact line of the spec, please? I cannot find it
> > > > > :(
> > > >
> > > > It is mentioned in HARMONY-2145 description:
> > > >
> > > >
> > > > http://java.sun.com/j2se/1.5.0/docs/guide/jvmti/jvmti.html#CompiledMethodLoad
> > > >
> > > >
> >
> > --
> > Egor Pasko
> >
> >
>