On Mon, Sep 1, 2014 at 8:46 AM, MacGregor, Duncan (GE Energy Management) <duncan.macgre...@ge.com> wrote: > Has anybody else tried doing this sort of thing as part of their > invokeDynamic Implementation? I’m curious if anybody has data comparing the > speed of GWT & class comparison based PICs with checks that require getting a > ClassValue and doing a Map or Set lookup?
I've thought about trying this. Here's the short version of JRuby's class hierarchy + lookup mechanism: * Each class has a map of methods and a lookup cache. The method map only contains methods from that class, but the lookup cache (which all lookups pass through) may eventually hold all methods from superclasses as well. This is class-level method caching. * Call sites look up method on the receiver's natural class, which will populate an entry in the class-level lookup cache if none is there. * The lookup cache entries are a tuple of class serial number + method object. The serial number represents the class's version at lookup time. * When any method table changes, the serial numbers of all child classes get bumped, so their already-cached lookup entries are now invalid. Upon next lookup, a stale entry will be replaced. On the call site guard side, we have used both serial number comparison and class reference comparison. Using the serial number has a couple: no hard references to classes in the call site, classes that are identical can be made to look identical by reusing serial number, etc. The disadvantage is that it requires an additional dereference to get the current serial number off incoming classes every time. For class comparison, we dereference the metaclass field on the object to get a RubyClass object reference, store that at the call site, and do direct referential comparisons in the call site guard. I should note that most objects in JRuby are of the same JVM type. We generally don't stand up a JVM class for every Ruby class, since Ruby classes are sometimes (frequently?) created and thrown away as part of normal execution. This could be considered a sort of CHA, since the serial number indicates not just the version of the class, but the version of all its ancestors. It could be improved, however, to be a calculated value based on the actual shape of the class, so two different classes with the same superclass and no methods of their own would look the same to the guard. I have only done basic experiments here. - Charlie > > Duncan. > _______________________________________________ > mlvm-dev mailing list > mlvm-dev@openjdk.java.net > http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev _______________________________________________ mlvm-dev mailing list mlvm-dev@openjdk.java.net http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
