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
