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? 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. -- Egor Pasko
