Could the weak ref wiring be done lazily, so the overhead is only incurred when someone sets an ivar on a java object?
e.g. when a java object enters jruby, it gets a new lightweight wrapper, but when someone does an ivar get/set on it, it looks for the ivar holder for the java object in the weak map, and attaches it to the wrapper (or creates one and adds it to the weak map if it is missing). This way, java objects that are just passing through, don't take the hit of wiring up a Reference, but when it is needed, it automagically works (with perhaps a bit more overhead than at present). Of course, it gets complicated by other things like method dispatch - if someone defines a ruby method on a java object, then they would want that used in preference to the java one when in ruby, so you would always have to lookup the holder object in the weak map when calling methods anyway. Making people explicitly request the behaviour might be more efficient. On 13 June 2010 01:41, Charles Oliver Nutter <head...@headius.com> 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. > > What do you all think? > > - Charlie > > --------------------------------------------------------------------- > To unsubscribe from this list, please visit: > > http://xircles.codehaus.org/manage_email > > > --------------------------------------------------------------------- To unsubscribe from this list, please visit: http://xircles.codehaus.org/manage_email
