From: Charles Oliver Nutter <charles.nutter@...>
Date: 2007-10-28T16:06:32+09:00
Subject: Re: JRuby disabling ObjectSpace: what implications?

ara.t.howard wrote:
 > hmmm.  ok i'm brainstorming here which you can ignore if you like as i
 > know less that nothing about jvms or implementing ruby but here goes:
 > what if you could invert the problem?  what i objects knew about the
 > global ObjectSpaceThang and could be forced to register themselves on
 > demand somehow?  without a reference i've no idea how, just throwing
 > that out there.  or, another stupid idea, what if the objects themselves
 > were the tree/graph of weak references parent -> children.  crawling it
 > would be, um, fun - but you could prune dead objects *only* when walking
 > the graph.  this should be possible in ruby since you always have the
 > notion of a parent object - which is Object - so all objects should be
 > either reachable or leaks.  now back to drinking my regularly scheduled
 > beer...


Continuing this discussion here...

Please, continue to brainstorm. I don't claim to have thought out every 
aspect of this problem or every possible solution. I'd *love* to 
discover I've missed an obvious fix.

Your idea has come up in the past, and it would probably eliminate the 
cost of an ObjectSpace list. However that doesn't appear to be where we 
pay the highest cost.

The two items that (we believe) cost the most for us on the JVM are:

- Constructing an extra object for every Ruby object...namely, the 
WeakReference object to point to it. So we pay a 
memory/allocation/initialization cost.
- WeakReference itself causes Java's GC to have to do additional checks, 
so it can notify the WeakReference that the object it points at has gone 
away. So that slows down the legendary HotSpot GC and we pay again.

I believe the parent -> weakref -> children algorithm is used in some 
implementations of ObjectSpace-like behavior, so it's perfectly valid. 
But again, there's certain aspects of ObjectSpace that are just 
problematic...

- threading or concurrency of any kind? No, you can't have 
multithreading with ObjectSpace, nor a concurrent/parallel GC (and it 
potentially excludes other advanced GC designs too).
- determinism? Matz told me that "ObjectSpace doesn't have to be 
deterministic"...but when it starts getting wired into libraries like 
test/unit, it seems like people expect it to be. If we can say OS isn't 
deterministic, then *nobody* should be relying in its contents for core 
libraries, and we could reasonably claim that each_object will never 
return *anything*.

- Charlie