On 28.10.2007 08:06, Charles Oliver Nutter wrote:
> 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.

IMHO ObjectSpace should not be implemented in Java land.  Why?  The JVM 
has to keep track of instances anyway and implementing this in Java via 
WeakReferences seems to duplicate functionality that is already there. 
Did you consider using "Java Virtual Machine Tools Interface"?

http://java.sun.com/javase/6/webnotes/trouble/TSG-VM/html/gbmmt.html#gbmls

You could either follow the same approach of the heapTracker presented 
on that page and use a flag or require a lib that enables ObjectSpace 
(because of the overhead of instrumentation).

Alternatively there may be another method that does not need 
instrumentation and that can give you access to every (reachable) object 
in the JVM.

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

I'd reformulate the requirement here: ObjectSpace.each_object must yield 
every object that was existent before the invocation and that is 
strongly reachable.  I believe for the typical use case (e.g. traversing 
all class instances) this is enough while leaving enough flexibility for 
the implementation (i.e. create s snapshot of some form, iterate through 
some internal structure that may change due to new objects being created 
during #each_object etc.).

Kind regards

	robert