harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Ivan Popov" <ivan.g.po...@gmail.com>
Subject Re: [drlvm][jvmti] Profiling support - Compiled Method Load event
Date Mon, 11 Dec 2006 16:31:35 GMT
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
>
>

Mime
View raw message