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.
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.
