Perhaps, though the opt-in wouldn't be per object, it would be per class. You'd essentially specify that you want to use instance vars or singletons with a given Java type.
I will probably at least try to mock up the lazy ivar logic, which seems like it could work. The singleton logic...that's tougher. On Mon, Jun 14, 2010 at 8:42 AM, Brandon Hauff <brandon.ha...@buckle.com> wrote: > 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 >> > > --------------------------------------------------------------------- To unsubscribe from this list, please visit: http://xircles.codehaus.org/manage_email
