SwitchPoint strategy for JRuby class modification invalidation

[Charles Oliver Nutter]

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