Hi Egor, Nice benchmark. Yes, the cost of not devirtualizing as well as not hoisting ldintfcvt is high. I played around a little with this too and have some comments and questions...
First some high level stuff.... 1) What are the instructions like ldintfcvt, ldvfnslot, etc.in the jit dump? Are these part of jitrino HIR? While they seem more or less readable, is there any doc describing them ... since they are the first level internal representation, and anyone who wants to work with the jit needs to understand them? 2) When experimenting with the JIT related command line options to ij.exe-Xjit...I found many of them listed in the vm/doc/GettingStarted guide...Just FYI for interested folks. Please see below... On 10 Jul 2006 22:44:52 +0700, Egor Pasko <[EMAIL PROTECTED]> wrote:
>I looked through the list of TODO projects for JIT [1] and decided to write a >microbenchmark detecting how good interface call devirtualization works in JIT >(see below) >Jitrino.OPT showed very-very slow (~2.5 times slower than JRockit (1.5 /linux)). > A strange thing, "interface call devirtualization" >would have boosted JRockit's performance too (I checked that with a >slightly changed benchmark).
Yes, this optimization would have helped here...I also converted this interface dispatch effectively to a virtual dispatch in your test and the performance significantly improves with the resultant devirtualization... Block L8: Predecessors: L7 Successors: L11 L9 I74:L8: I40:ldvtable t13 ((t27)) -) t28:vtb:cls:IntfcImpl I41:getvtable cls:IntfcImpl -) t29:vtb:cls:IntfcImpl I42:if ceq.vtb t28, t29 goto L11 GOTO L9 Block L9: Predecessors: L8 Successors: L14 UNWIND I37:L9: I43:tauhastype t13,cls:IntfcImpl -) t30:tau I44:ldvfnslot [t28.IntfcImpl::inc] ((t27)) -) t31:method:inc I46:callimem [t31](t13) ((t27,t30)) -) GOTO L14 Block L11: Predecessors: L8 Successors: L12 UNWIND I38:L11: I48:--- IntfcImpl::inc: () I49:chknull t13 -) t32:tau GOTO L12
So, that would be interesting to implement it! >Seems like the best choice is to start from a couple of easy heuristics: >* if there is only one loaded class to implement the interface, choose it >* if there are more, choose the one with it's method invoked earlier (compiled >by some JIT, possibly, some other JIT),
If we forget the profile guidance for now, could you please elaborate more about how we should do this and on what exactly is happening now? BTW, do we currently raise the IncompatibleClassChangeError if the objectref's class does not actually support the interface? Do we cache the interface tables per class object and can we improve this cache search in the optimization? In non trivial cases where many classes implement the same interface, the cache search may be more expensive than the slot look up. We could also virtualize and then devirtualize the interface invocation when we can...somewhat like the jit dump above. What do you think?
>* if we have many candidate methods that are compiled, choose the most frequent >one (need a method-entry profile, the feature is likely to stay untouched for >a while, I guess) > 3. Should I create a JIRA for the issue ASAP? :)
I would say yes, let's create a JIRA issue Thanks, Rana ---------------------------------------------------------------------
Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
