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 Thu, 07 Dec 2006 14:49:25 GMT
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
:(

> > 2. VM may want to restore the whole inline tree. How would you do that
> >    with per-instruction notifications?
> > 3. Guys, did you try RI and look how it behaves? Does it report each
> >    instruction separately? I doubt so. Let's make it as close to RI as
> >    possible (for compatibility reasons). I should not be difficult.
> >
> 
> 

-- 
Egor Pasko


Mime
View raw message