Fabio Kung wrote:
On Fri, May 2, 2008 at 6:00 AM, Christian Seiler <[EMAIL PROTECTED]
<mailto:[EMAIL PROTECTED]>> wrote:
Charles Oliver Nutter-2 wrote:
>
> - Classloader-based runtime separation; instantiating a JRuby
instance
> instantiates a new classloader and all of JRuby runs under that. This
> would isolate JRuby instances and allow access to the runtime through
> getClass().getClassLoader().getRuntime() always rather than having to
> have a Ruby metaclass around. This in turn would make it possible
to do
> things like normal Java serialization, instantiable Ruby types
without a
> runtime passed in, and more. We need to revisit this and try to
make it
> happen.
>
Wouldn't that mean that JRuby instances can't easily share objects any
longer? I'm thinking of things like Rails instances sharing an
EHCache or
Spring application contexts. This is really a sweet spot of JRuby
IMO that
you can efficiently share data inside a single JVM without the need
to do
any inter process communication (as long as you don't need to scale
out).
Actually they can, as long as shared object classes are loaded by a
common parent classloader. It would work if the JRuby instances have a
single common classloader (application classloader, servlet context
classloader, ...) and shared object classes were loaded by this parent
classloader.
The way this would work internally is that the JRuby "Main" class would
not directly reference any of the other classes; instead, it would
launch a new JRubyClassLoader that loads in the other classes. You
wouldn't actually ever know that there are classloader tricks involved,
but it would eliminatea lot of indirection to get at the runtime from
within Ruby classes. And like normal Java classes, Ruby objects would
always know "where they came from", so they could be
serialized/deserialized more easily (in theory).
Charles, I'm not sure if this feature would really be positive, but I'm
not so confident with JRuby internals. I can only see some of the
possible drawbacks that should be considered:
- It would be like a "global access" to Runtimes. Any semelhance with
thread-local variables?
Thread-local variables are currently stored based on the runtime anyway;
this would not change. We'd just get at the runtime in a slightly
different way.
- It would require an ugly cast to RuntimeClassLoader, as
getClass().getClassLoader() doesn't have getRuntime().
It would, but that would be unlikely to incure as much performance hit
as the indirection mechanisms we have now do.
I'll probably try to come up with a prototype to show you all, and we'll
see how it works.
- Charlie
---------------------------------------------------------------------
To unsubscribe from this list, please visit:
http://xircles.codehaus.org/manage_email
