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.184 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=jq426BBGOEdnn5b427dGamfe5U0VwIZr7HPXL6vGLDi4k7tVzdDhTvC8uZCOwayzxa3anRfPh0mvKy0SkMNfJXFEmEF6jlz44WSD1ew1XRPplUXoDjLqFsAeRsQGnwfWDg+NvvyiKyYvCwEySOwa7grVGtW85g09NVLDEzlfmao=
Message-ID: <1e3228450612110350y19414087k8304a83b3388b454@mail.gmail.com>
Date: Mon, 11 Dec 2006 14:50:26 +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: <elijq3$mes$1@sea.gmane.org>
MIME-Version: 1.0
Content-Type: multipart/alternative;
	boundary="----=_Part_194885_27381347.1165837826254"
References: <1e3228450611100406n1d0ea58fp2c778fb9a3c49458@mail.gmail.com>
	 <ek6l6b$eem$1@sea.gmane.org>
	 <1e3228450611290749y4583024ev8cd9a0d9f3104f4a@mail.gmail.com>
	 <el1b2n$a87$1@sea.gmane.org> <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>

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

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

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.

Thanks,
Eugene.

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

------=_Part_194885_27381347.1165837826254--