2007/10/29, Charles Oliver Nutter <charles.nutter / sun.com>:
> mortee wrote:
> > Charles Oliver Nutter wrote:
> >> 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.
> >
> > [...]
> >
> >> 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.
> >
> > Sorry for the extremely uninitiated and naive question - but when you're
> > about to enumerate each object in an application, aren't you interested
> > only in this application's objects anyway? So why would you have to lock
> > anything about the other ruby apps in the same process? Is that kind of
> > distinguishing objects impossible on the GC/enumeration level?
>
> As far as I know there's no way to have JVMTI enumerate only objects
> created by a specific application in a given JVM. So any sort of
> ObjectSpace impl based on it would have to take that into consideration.

Hm, if you host different applications in the same JVM you probably
need separate class loaders anyway to separate changes on classes.
Maybe you can use that to partition the heap. Alternatively you could
use IterateOverObjectsReachableFromObject() and start from main.  Just
a few wild guesses.

Btw, but the issue with stopping the world would still not go away.
Too bad.  A possible solution would be to implement the callback in a
way that it places all references in a Java collection.  Only after it
finishes the Ruby land callback is invoked for each instance. The
downside is that you need more space (i.e. for the collection which
could become largish) but on the plus side is that you do not have any
overhead (other than incurred by JVMTI) during "normal" operation and
you can limit the stop the world time to just the copying phase which
might be acceptable.  Charles, what do you think?

Kind regards

robert