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 Mon, 11 Dec 2006 14:39:24 GMT
On the 0x23C day of Apache Harmony George Timoshenko 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
> >>>>>> 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
> >>>>>> 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,
> >>>>> should register several code blocks for the same inlined method
> >>>>> the method's code was split into parts) through the
> >>>>> compiled_method_load(...) interface. This can be done completely
> >>>>> the JIT side.
> >>>>> What do you, guys, think?
> >>>> No doubts it can be done on the JIT side, but what is the purpose of
> >>>>
> >>>> 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
> >>>> 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

thanx! Now I read it more carefully. Event that we are sending from
JIT (CompiledMethodLoad) gives the following info on *each*
compilation for our interest:
* the method
* method size
* compiled code start address
* map: [addr -> "location"], where 
  * "location" is a start address of some memory chunk,
  * each whole "location" corresponds to *only one* bytecode offset, 
  * all reported locations have to be _adjacent_.
  // if a bytecode offset is not known (example: native code), we can
  // report something different or even 0, which is "no info".


* in Jitrino.OPT we guarantee that each machine instruction
  corresponds to only _one_ original bytecode offset. Thus, each
  instruction might be safely represented as a "location"

* but we can join several adjacent instructions with identical
  bytecode offset into _a single_ location. Seems like more natural
  and easy to perform fast. I guess, RI does that.

* with inlining and trace scheduling compiled code for a single method
  can be split into several non-contigous blocks. For example, we have
  some chinks of methods X and Y intermixed like this:
  "X.1,Y.1,X.2". To overcome we may:
  * raise a single event for X: 
                       method_size=X.1.size + Y.1.size + X.2.size,
                       [X.1.start -> bcoff1, 
                        Y.1.start -> 0,
                        X.2.start -> bcoff2])
  * raise 2 events for X:
                       [X.1.start -> bcoff1])
                       [X.2.start -> bcoff2])

I would highly appreciate if some JVMTI guru steps down from Olymp and
tells which of two is the best, or at least says what RI does in that
case (or, maybe, RI does not generate non-contigous blocks?)

I like the second approach (raise 2 events)

Egor Pasko

View raw message