On Wed, Jan 6, 2010 at 10:29 AM, Rob Heittman <[email protected]> wrote: > 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.
I have the same concern about the state. Current Ruby runtime has many states. Some of them are ok for VM wide state, but others are not. I think we should decouple no VM wide state from Ruby runtime. > 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. Yes, OSGi issues should be resolved since people want to use JRuby on OSGi environment. To make this happen, JRuby needs to consider OSGi specific classloading way. Current JRuby doesn't work well with OSGi. -Yoko > 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 >> >> > > --------------------------------------------------------------------- To unsubscribe from this list, please visit: http://xircles.codehaus.org/manage_email
