Class hierarchy analysis and CallSites

[Charles Oliver Nutter]

On Mon, Sep 1, 2014 at 8:46 AM, MacGregor, Duncan (GE Energy
Management) <duncan.macgregor at 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 at openjdk.java.net
> http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev