I have to think through this a bit. It should not be a problem to have a static runtime, and make everything to do with class loading classloader-specific. My concerns have to do with state; we have situations where the same application embeds several JRuby runtimes that persist different state and serve different purposes -- for example, a Rails app and various user-interactive scripting contexts.
It's OK for all of these to share the same class loading environment (and we do actually share them now as much as we can by setting the class cache explicitly). The Red Bridge stuff currently makes a strong effort to separate out Ruby application global state from runtime state -- but for various little reasons we haven't been able to go there 100% yet. I haven't drilled into it in great detail, but one fear I have is of there being a lot of overhead (and possibly resulting synchronization and delay) associated with re-establishing state, when one runtime is being used to serve multiple purposes. There is also some study to be done here from the OSGi perspective. Right now I think -- fairly -- there is a lot more fit for JRuby with the command line and JEE class loading models than OSGi. This almost certainly correctly reflects installed base. But I believe that OSGi, or at least some variation on the theme that provides better classloader isolation, organization, and lifecycle support, is extremely important looking forward. Since this proposed effort is Not Trivial, it seems like this is a good opportunity to look at these user stories more intently. I was planning to have a fresh look at OSGi issues in JRuby 1.4 due to a recent post on the list anyway. On Wed, Jan 6, 2010 at 9:58 AM, Charles Oliver Nutter <[email protected]>wrote: > Ok, it's time to start biting off a big change: we need to make the > JRuby runtime be classloader-global (i.e. static). > > There's many reasons for this: > > * You won't have to pass a Ruby instance into object construction > * Serialization will work, since it will just be able to grab the > classloader-global Ruby instance when constructing > * All core classes will be able to start inline caching calls back to > Ruby (where they do almost *no* caching right now) > * Replacing arbitrary pieces of Java code with Ruby code will be *much* > easier > > And the list goes on. > > Perhaps the most important person I'd like to see in this discussion > would be Yoko Harada, since it may be possible to hide all this behind > RedBridge and the 223/BSF engines. But I'd like to hear from others > interested in the above features/changes, or from anyone with concerns > about how this change might affect their code. > > For the record, this will almost exclusively impact only users > embedding JRuby or calling into JRuby from non-Ruby code. Users > running plain-old-Ruby probably will never see any real impact. > > - Charlie > > --------------------------------------------------------------------- > To unsubscribe from this list, please visit: > > http://xircles.codehaus.org/manage_email > > >
