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. 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 <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> 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 > >
