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
