From: Helder Ribeiro <helder@...>
Date: 2007-10-29T22:30:13+09:00
Subject: Re: JRuby disabling ObjectSpace: what implications?

On Oct 28, 3:39 pm, Charles Oliver Nutter <charles.nut...@sun.com>
wrote:
> Robert Klemme wrote:
> > On 28.10.2007 17:19, Charles Oliver Nutter wrote:
> >> You just hit on exactly why we don't use JVMTI for ObjectSpace. It
> >> would certainly work, but it would add a lot of overhead we'd never
> >> expect people to accept in a real application. Plus, it would track
> >> far more object instances than we actually want tracked.
>
> > Why is that?  I mean, you could selectively decide which instances to
> > track.
>
> Actually, we do that a bit already. For example, we do not track arrays
> constructed during argument processing, since they are typically
> transient. The problem is that we could only choose to track all Ruby
> objects, for example...which would cripple other JRuby apps running in
> the same process.
>
> In general, though, we haven't explored JVMTI because we want JRuby to
> be the best production environment for deploying apps, and nobody will
> EVER turn on JVMTI on their production servers.
>
> >>> Alternatively there may be another method that does not need
> >>> instrumentation and that can give you access to every (reachable)
> >>> object in the JVM.
>
> >> If there is...we haven't found it. The "linked weakref list" has been
> >> the least overhead so far, and it's still a lot of overhead.
>
> > Hmm, but there are iteration methods like #each_object:
> >http://java.sun.com/j2se/1.5.0/docs/guide/jvmti/jvmti.html#Heap
>
> I was referring to non-JVMTI solutions, but you're right, JVMTI does
> provide this capability.
>
> > Did you put them down because of the "stop the world" approach?  I'd say
> > that would be ok - at least it's better than not having ObjectSpace. And
> > also, there would be no overhead.  Question is only whether it's ok to
> > invoke arbitrary byte code (which would happen during the iteration
> > callback).
>
> Is it really ok? You need to remember that JRuby opens up the
> possibility of running many, many applications in the same process, as
> well as asynchronous algorithms with true parallel threads. We can't
> expect people to cripple all that so they can walk EVERY object in the
> system. "Stop the world" is awful when you start breaking the ability to
> do many things in parallel, as you can in JRuby.
>
> But it may be that for cases where each_object is needed, this is a
> reasonable thing to do.

Exactly. I think that each_object rarely has to go into production
code, but is very handy (and, to be honest, just fun, really) in
debugging/testing/experimenting. For those type situations, I don't
really think a "stop the world" approach is so terrible. I find it
less of a disturbance than having this off-code switch.


I think if someone were to submit an
> implementation of each_object that uses JVMTI, we would certainly accept
> it :)
>
> >> ObjectSpace is just not compatible with any GC that requires the
> >> ability to move objects around in memory,
>
> > I don't think that moving is an issue.  If it were, JVM's would not work
> > the way they do (object references are no pointers to memory locations).
> >  In other words, all programs would have the same problems #each_object
> > had.
>
> The problem is not so much that the object references move as that you
> would have to lock the memory locations for some period of time to be
> able to walk the object table. And I think that's *bad* especially when
> we're looking at JRuby allowing folks to run dozens of apps in the same
> process and memory space out of the box. We can't lock things down like
> that.
>
> - Charlie