• I've taken a preliminary stab at factoring/decomposing the IRubyObject interface. I can omit/undo this for the merge back to trunk if it needs more thought. The reason for doing this is to permit (eventually) non-RubyObject/IRubyObject class/object implementations. Not necessarily to support lightweights, either (though that would be a goal) – there is a pretty good case to be made, for example, for not defining the variableStore (was instanceVariables) and dataStruct fields for most built-in types (storing vars externally for those types on the rare occasion someone wants to, see experiment in bdortch/bnw), and always instantiating a (final) variableStore for user-defined types. Another interesting idea might be having RubyNumeric subclass java.lang.Number, to eventually simplify method signatures that might take raw/native (java.lang) or JRuby built-in values.

• I've renamed some methods (and deprecated the old names) in an effort to impart some consistency/clarity. The changes involving (the overloading of) "instance variables" are really necessary – I've put a lot of effort into untangling that knot, the current (trunk) implementation being full of bugs, thread-safety violations, and so on. The new code clearly distinguishes among ivars, cvars, constants and "internal" variables (like those used when marshaling Ranges), and in code I'm currently working on, actually treats them differently (constant storage/lookup is optimized). Some of the other changes (searchConstant in place of getConstant) are primarily for clarity. I've retained, but deprecated, the old names.

As I said, I should have this stuff wrapped up in the next day or so. There are a couple of pieces not yet in SVN, notably a ConcurrentModuleVariableStore (in progress) that includes the constant optimization I mentioned, and also a concurrent implementation of RubySymbol.SymbolTable that shows a 15% improvement in bench_symbol before I've even hooked up the "fast" lookup method. The performance gains of all the "concurrent" code should be even more pronounced in multi-threaded benchmarks (I'm working on some).

-Bill