On 2010-06-12 10.41, Charles Oliver Nutter wrote:
One of the primary remaining perf challenges for JRuby is the cost of
bringing Java objects into the Ruby environment. Currently, all
objects get wrapped with a small wrapper object that implements
IRubyObject. This is primarily because all our call logic requires
receivers and arguments to all be of type IRubyObject.
We also ensure that this wrapper object is preserved by stuffing it
into a large weak map, so that if the same object enters Ruby in a
different place in the code, it gets the same wrapper. We do this
wrapping and for a few reasons:
* Users sometimes add instance variables to Java objects floating
around Ruby land
* Users sometimes singletonize (class<< obj) Java objects in Ruby
Unfortunately, maintaining that weak map has an extremely high cost
just to provide the above two features. Supporting these features
implicitly also means we can never move away from having a wrapper,
which would be necessary to get Java call performance to the same
level as Ruby to Ruby or Java to Java invocations.
So I think we need to start moving toward these features being opt-in
rather than implicitly available.
I propose the following:
* For now, Java objects will continue to be wrapped, but there will be
no effort made to preserve the wrapper; we'll simply wrap it with that
lightweight object every time it enters. If it stays in Ruby, it will
obviously keep the same wrapper as long as it is referenced.
* Those two features that require all instance of an object to get the
*same* wrapper will be opt-in by calling a method on the object's
class, as in ArrayList.enable_object_features (or something like
that). Until this method is called, there will be no guarantee that
instance variables on an object instance will exist on all references
to that object, since those references may enter Ruby through a
different path and end up with a different wrapper. The same goes for
singletons. After calling this method, we will start using the weak
map to preserve the wrappers so that singletons and instance vars will
work as expected.
Moving away from these features being implicitly available will help
us start to approach Java performance for Ruby to Java calls, and I
think this is the only way to do it.
I do see the need to make these kind of changes, based on their
performance impact. But I still have reservations (maybe because I'm one
of the people who write code that usually sets instance variables on
Java objects, and opens up the metaclass.) Specifically, these features
are very useful in testing, for example. However, I guess that can still
be done by using the enable_object_features on the framework side,
although that feels a bit ugly.
I am uncomfortable with not making any guarantees the wrapper will be
the same. That will lead to lots of silent failures far away from where
the point of the problem which will be extremely hard to track down for
people. I would prefer it if we just stopped doing it period, without
the enable_object_features call. I think that would make the transition
easier.
Cheers
--
Ola Bini (http://olabini.com)
Ioke - JRuby - ThoughtWorks
"Yields falsehood when quined" yields falsehood when quined.
---------------------------------------------------------------------
To unsubscribe from this list, please visit:
http://xircles.codehaus.org/manage_email
