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
------------
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.
Thanks,
Eugene.
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
