I was sick and not reading this thread. I have code which uses both ivars and singleton objects. I can say in both instances I could mark the classes which would use these features because I know in-advance that those classes will add this behavior. For people who know JRuby already this is not a problem to make this change.
My reservation on this is the fact that it violates least surprise. As a new user I will be pretty surprised when my stuff disappears. This is a hard problem and if we can at least reduce the scope by making ivars work then I can probably live with singletons not working as expected for new users. The number of people annotating ivars over creating singleton behavior is probably huge. -Tom On Tue, Jun 15, 2010 at 2:51 AM, Charles Oliver Nutter <head...@headius.com> wrote: > 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 > > > -- blog: http://blog.enebo.com twitter: tom_enebo mail: tom.en...@gmail.com --------------------------------------------------------------------- To unsubscribe from this list, please visit: http://xircles.codehaus.org/manage_email
