2007/10/28, Charles Oliver Nutter <charles.nutter / sun.com>:
> 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.

> 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.

Well, it depends on the overhead and on the invocation model.  I
assumed you would be starting a JVM per process but your other remarks
sound more like there is one JVM for JRuby programs...

> > 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.

Ok, I see I need to dive further into JRuby before I discuss this further. :-)

> But it may be that for cases where each_object is needed, this is a
> reasonable thing to do. I think if someone were to submit an
> implementation of each_object that uses JVMTI, we would certainly accept
> it :)

Hint, hint... :-)

> >> 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.

I don't understand this remark of yours. If you implement this in Java
land (as you did apparently with WeakReferences) then there is no need
to lock anything. You just traverse the list (or a copy of the list)
and if a ref has been set to null you do not pass it to the callback.

If it is some kind of native code (possibly via JNI or other
interfaces) probably more care has to be taken, although I'd assume
that JNI takes care of this (i.e. once the callback is invoked with a
non null argument the object stays life until after the callback
returns unless you clear that reference of course).

Traversal during #each_object in that respect is similar to traversal
through an ordinary collection - during that a GC can occur just the
same but that does not affect the traversal in any way.

What am I missing?

Kind regards

robert