I wanted to outline how I plan to make JRuby's current class modification check eventually be all SwitchPoint driven.
JRuby, like some other dynamic languages, allows runtime modification of pretty much every class in the system. Usually this only happens at boot time, but since it can potentially happen any time we need to check for it. This basically means that we can't simply do a type check in call site guards; we need a modification check. Current JRuby achieves this by having all classes in the system weakly reference their children. Each class object has a serial number used when caching methods loaded from that class. Modifying a class anywhere in the class hierarchy cascades down child classes, spinning each of their serial numbers in turn. On non-indy JRuby, each call site caches a tuple of [serial, method], and the guard compares that serial number with one received from the class (cache.serial == object.getMetaClass().getSerial()). With indy today, the test for GWT does the same logic, with the success paths routing to a direct handle. The way I plan to change it works like this: * Instead of each class having a serial number, they'll have a SwitchPoint...one per class. * The invalidation cascade will then invalidate SwitchPoints and replace them with new ones. * The test for GWT will then be reduced to an object identity check (metaclass == object.getMetaClass) which should be slightly faster. * For cases where a real Java type is known, it will be an object class identity check (javaClass == object.getClass()), avoiding an interface call to getMetaClass(). I believe this will allow for the cheapest-possible guard at indy call sites in JRuby. Concerns: * For a descendant hierarchy of N classes, I'll need to do N invalidateAll calls. This is not ideal, since those calls are very heavy. Thoughts on this? - Charlie _______________________________________________ mlvm-dev mailing list [email protected] http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
