Great. That's what I was dreaming of. :) There's one more issue related to HARMONY-2769 subject. I guess that inlined method code region may be equal to it's caller method region. E.g. method a() is called from method b() which does nothing except calling a(). b() in it's turn is called from method c(). Method a() could be inlined to b(), and b() could be inlined to c(). Thus code regions for a() and b() are the same, since b() has no it's own instructions but only those inlined from a(). In this case VM using only region information couldn't determine which of a() and b() is caller and which is callee. It seems that to solve this problem we need JIT to report for the method not the most outer method in inline chain (as it does in H-2145-JIT-side.patch<http://issues.apache.org/jira/secure/attachment/12345590/H-2145-JIT-side.patch>) but the first-hand caller method. Is it possible for JIT?
On 18 Dec 2006 18:09:45 +0600, Egor Pasko <[EMAIL PROTECTED]> wrote:
FYI: Just to track things right I filed a new JIRA with proposal to InlineInfo unification: HARMONY-2769 [drlvm][jit] use per-region InlineInfo from global storage in VM to report stack frames of inlined methods depends on HARMONY-2145, as expected. Feel free to vote :) On the 0x223 day of Apache Harmony Egor Pasko wrote: > On the 0x222 day of Apache Harmony Eugene Ostrovsky wrote: > > Do I understand correctly that per-call-inline-info is a list of inline > > chains for every call instruction offset within a code chunk? > > yes > > > If so, think we may replace per-call-inline-info with > > per-region-inline-info. Why can't we use per-region-inline-info for stack > > tracing. > > Relying on per-region-inline-info introduces some constraints for JIT > design. Specifically, it becomes not easy to move instruction regions > across method boundaries. > > On the other hand, we do not move calls today (and I doubt we will > since it is easier to inline than prove that side effects allows > swapping two calls). JIT guys, comment here if you have other opinions! > > So, frankly, I do not see any strong reasons to stick with > per-call-inline-info. The reasons to use them might be: > * less memory consuming than region-based (that's an open question, > though), in non-JVMTI mode we can fall down to call-based with > region-based=OFF > * more precise (JIT mechanisms guarantee that this info won't be lost) > > Although, there is a disadvantage of per-call-inline-info: > * we cannot afford reporting stack frames on exceptions (because there > are a lot fo potentially exceptional instructions and storing inline > chains for all of them would be ineffective) see HARMONY-2114 > > > The other question is: which component should collect and process > > inline-info? > > The current approach is that JIT collects the data and provides interface > > for VM to extract useful information from it. > > The other possible approach could be in using JIT to VM notifications about > > compiled method (as George proposed). VM can store the inline info by itself > > and process it on demand without disturbing JIT. > > I like this idea! Just a reminder: in this approach VM should not forget to: > * free associated resources, when code chunks are freed > * keep the inline tree to report stack traces properly > > currently, you have all tools to implement this proposal on the VM > side. per-call-inline-info is used in st_print_stack(...) and in some > other tricky places. To completely eliminate per-call-inline-info you > will need to retarget those places at using per-region-inline-info. > > Anyway, it is worth a try. We can then measure how much space we saved > in JVMTI mode and in default mode. That would be interesting. > > > What do you think about these proposals? > > Using *one inline-info* approach is better than using two. So, I support > your unification proposal. AFAIR, Eclipse is sensitive to reporting > stack precisely, so, there is something to check the prototype on. > > > On 10 Nov 2006 20:27:45 +0600, Egor Pasko <[EMAIL PROTECTED]> wrote: > > > > > > On the 0x21D day of Apache Harmony Eugene Ostrovsky wrote: > > > > >BTW, I am curious, is it OK for TI when a method is compiled several > > > times > > > > and put on different addrs? > > > > > > > > Yes, it's ok. All compiled forms of the method must be reported. > > > > Moreover when compiled form of the method is unloaded from memory it > > > must be > > > > reported with Compiled Method Unload event. > > > > We should to think about this also. > > > > It seems to me that most natural way to implement CMU > > > event is to iterate > > > > over all methods of class being unloaded and all theirs inlined methods. > > > > > > yes, sure, so we need to store the inlining data from JIT until unloading > > > > > > > The similar problem is with GenerateEvents function ( > > > > > > > http://java.sun.com/j2se/1.5.0/docs/guide/jvmti/jvmti.html#GenerateEvents > > > ). > > > > It should report all already compiled methods at any the time, on > > > agent's > > > > request. > > > > It can be done also by iterating over all loaded class -> their methods > > > -> > > > > their inlined methods. > > > > > > > > What do you think? > > > > > > The question is where to store this info. AFAIK, there is a special > > > CodeChunkInfo->_jit_info_block which is OK for that. Some info is > > > stored there already, i. e. mapping of call instructions into "inline > > > chain" they are in (so called per-call-inline-info). That's for > > > precise stack traces (which is a necessity). > > > > > > Here we have a "region"-inline-info. Which is for TI. We can store it > > > in the CodeChunkInfo->_jit_info_block, but, unfortunately, it is not > > > typed, and is just a memory block. JIT is responsible for > > > serializing/deserializing to/from it. What I am dreaming of is a > > > tagged _jit_info_block. So "jit info" be a list of mem blocks, each > > > marked with it's tag, so appropriate info can be found more naturally > > > (not deserializing all big code block) > > > > > > Do you have alternative proposals where to store region-inline-info? > > > > > > There is one more issue, of course. Why not we unify both inline-infos > > > (per-call and region-based)? IMHO, region-based inline-info is less > > > precise (because of possible code motion in JIT), TI would not suffer > > > much of this (I hope), but precise stack traces can suffer. So, I am > > > for leaving both approaches as-is for now. > > > > > > It is also interesting how much memory would, for example, Eclipse eat > > > for region-based inline-info and for per-call-inline-info when > > > started? I cannot predict what is more compact. > > > > > > > Thanks, > > > > Eugene. > > > > > > > > On 10 Nov 2006 18:48:43 +0600, Egor Pasko <[EMAIL PROTECTED]> wrote: > > > > > > > > > > On the 0x21D day of Apache Harmony Eugene Ostrovsky wrote: > > > > > > Hello All. > > > > > > > > > > > > One more "hole" in current JVMTI Profiling implementation is > > > Compiled > > > > > Method > > > > > > Load event. > > > > > > > > > > > > Current VM doesn't report this event for methods that are inlined by > > > > > JIT. > > > > > > Though spec requires it to be sent for every compiled method: > > > > > > > > > > > > > > http://java.sun.com/j2se/1.5.0/docs/guide/jvmti/jvmti.html#CompiledMethodLoad > > > > > > > > > > > > To support the feature VM need to know about those inlined methods. > > > > > Right > > > > > > now I can see two possible approaches: > > > > > > > > > > > > 1. When VM initiates method compilation, it can ask the jit about > > > > > methods > > > > > > that were inlined to compiled method and report all of them. > > > > > > 2. JIT itself can notify VM about every compiled method by calling > > > some > > > > > > special interface function after the method compilation. > > > > > > > > > > > > I'm not sure about which approach is better. > > > > > > Each of them requires additional interface function (1.- to JIT from > > > VM; > > > > > 2. > > > > > > - from VM to JIT). > > > > > > > > > > > > The second approach seems to be more complicated in terms of VM - > > > JIT > > > > > > interaction. I mean that the following scheme "VM calls JIT's > > > function > > > > > to > > > > > > compile method. -> JIT's function in it's turn calls VM's function > > > to > > > > > notify > > > > > > about compiled methods. -> VM's function dispatches the event to TI > > > > > > agents..." introduces additional level of complexity than if "VM > > > calls > > > > > JIT's > > > > > > function to compile method. VM asks JIT about inlined methods. VM > > > > > dispatches > > > > > > event to TI agents." > > > > > > > > > > Correct me if I am wrong, I see the picture as: > > > > > (1): > > > > > 1.1. VM -call-> JIT (compile a method for me, please) > > > > > 1.2. VM -call-> JIT (gimme the list of addresses/functions) > > > > > 1.3. VM -call-> JIT (please, free your resources allocated for these > > > > > addrs) > > > > > > > > > > (2): > > > > > 2.1. VM -call-> JIT (compile a method for me, please) > > > > > 2.2. JIT -call-> VM (I generated code from addr X to addr Y, look at > > > this > > > > > one) > > > > > 2.3. VM -call-> TI (here is the code for you) > > > > > > > > > > (1) has a disadvantage in case one JIT instance compiles different > > > > > methods in parallel. And we should have a synchronized method addr > > > > > repository, which is not easy to wipe out in the right way. > > > > > > > > > > (2) seems more straightforward from the JIT side because JIT can > > > > > report method boundary addresses as soon as it determines them on > > > > > emitting. That simplifies JIT impl (no allocating/freeng/synch). > > > > > > > > > > BTW, I am curious, is it OK for TI when a method is compiled several > > > > > times and put on different addrs? > > > > > > > > > > > Ideas & suggestions are welcome. > > > > > > > > > > > > Thanks, > > > > > > Eugene. > > > > > > > > > > > > On 10/24/06, Eugene Ostrovsky <[EMAIL PROTECTED]> wrote: > > > > > > > > > > > > > > Hi all. > > > > > > > > > > > > > > It seems that we have most of JVMTI implemented in drlvm. Still > > > some > > > > > of > > > > > > > profiling support features is left. > > > > > > > I'm going to take a look on "VM Object Allocation" event. > > > > > > > I'll try to come up with design tomorrow. > > > > > > > > > > > > > > Thanks, > > > > > > > Eugene. > > > > > > > > > > > > > > > > > > > > > > > > -- > > > > > Egor Pasko > > > > > > > > > > > > > > > > -- > > > Egor Pasko > > > > > > > > -- > Egor Pasko > > -- Egor Pasko
