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 Tue, 12 Dec 2006 14:59:07 GMT
On the 0x23D day of Apache Harmony Ivan Popov wrote:
> 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.

sad news :(
I do not like this solution from JIT design point of view.
Let's look carefully how RI reports these cases (if they happen). And,
that would be cool to look at how popular opensource profilers handle
the situation (what are they, btw?)

BTW, JSE 6 JVMTI specs are exactly the same in this part. Which is...

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

-- 
Egor Pasko


Mime
View raw message