Charles Oliver Nutter wrote:
Future improvements to this will be breaking up dispatcher to act as an
adapter for separate methods, so all methods can be inlined individually
rather than inlining the whole dispatch switch. Also, CompiledMethod
must generate the actual call() method rather than a
commit #3984 breaks Webrick startup: active_support/dependencies.rb:266:in
`load_missing_constant'
--
Key: JRUBY-1200
URL: http://jira.codehaus.org/browse/JRUBY-1200
Is there a suite of tests that can be used to 'certify' a JVM for
JRuby? We have a Sun-certified JVM that we have tweaked for
transparent persistence, and I would like to ensure that it passes
any known tests that you have for JRuby.
-
The current persistence strategy saves the original metaclass in our
object store (but only keeps the classId .. everything else about the
metaclass is transient). When the object gets loaded, its metaclass
is a 'duplicate' of the original and dynamically hooks up to the
methods, superclass
Since the objects are detached from the runtime and are capable of
hooking themselves up when they come in from our persistent store, I
thought I would take a stab at serialization (Marshal.dump and
Marshal.load). I marked RubyObject Serializable and then tried this:
class Person
def init
STI should fall back to normal invocation when visibility changed
-
Key: JRUBY-1199
URL: http://jira.codehaus.org/browse/JRUBY-1199
Project: JRuby
Issue Type: Bug
Comp
JRuby benchFibStackDepth fails on server jvm
Key: JRUBY-1198
URL: http://jira.codehaus.org/browse/JRUBY-1198
Project: JRuby
Issue Type: Bug
Components: Compiler
Affects Versions: JRu
I've started to make changes to the call path for compiled code along
the lines of my earlier post. Basically I committed two changes this
evening:
1. Compiled code now retrieves a Dispatcher directly from the metaclass
and calls against that.
2. Dispatcher now retrieves a DynamicMethod instan
