Could the opt-in be in the form of a command line opt or a require 'somenewlib' which would likely be a lot easier to port and more clean than calling a method per object?
> -----Original Message----- > From: Charles Oliver Nutter [mailto:head...@headius.com] > Sent: Sunday, June 13, 2010 6:28 PM > To: dev@jruby.codehaus.org > Subject: Re: [jruby-dev] Improving Ruby to Java call performance: no > instance vars or singletons > > On Sun, Jun 13, 2010 at 11:19 PM, Charles Oliver Nutter > <head...@headius.com> wrote: > > On Sun, Jun 13, 2010 at 2:54 AM, Wayne Meissner <wmeiss...@gmail.com> > wrote: > >> 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). > > > > I've tried to think of a way to do this, but we'd need to be able to > > trigger all in-flight references to a given object to start using the > > ivars from the wrapper where we just added ivars. > > Actually, I may have just thought of a way to do this. > > * Upon access or modification of an instance variable, a wrapper adds > itself to our tracking map > * Wrappers that have not yet been tracked will know they are not being > tracked, and when an instance variable access happens they'll first go > look in the tracking map for the "master" wrapper > * Objects that don't ever access instance variables will never lift > themselves into the tracking map and never incur the weakref costs > > I think this could work! > > A similar technique might be able to work for singletonized Java > objects, although it has a higher potential of "poisoning" all > instances of a given type: > > * All Java proxy types would have a bit indicating whether an instance > of them had ever been singletonized > * When the first object of a given Java type gets singletonized, we > flip this bit and add that singletonized wrapper to the tracking map. > From then on, non-tracked wrappers for the same object will go to the > "master" wrapper for their metaclass behavior, and future references > will use the same wrapper. > * The poisoning effect: future wrappers for the same type will either > need to constantly ping the tracking map or else all instance of that > type will have to go into the weak map once again. > > Note that in order to completely eliminate the wrappers (or completely > eliminate the use of the tracking map, for now), both features need to > be addressed. Any better suggestions for handling singletons (other > than turning them off, which has my vote!) > > - Charlie > > --------------------------------------------------------------------- > To unsubscribe from this list, please visit: > > http://xircles.codehaus.org/manage_email >
