Message from discussion JRuby disabling ObjectSpace: what implications?

Path: g2news2.google.com!news1.google.com!eweka.nl!lightspeed.eweka.nl!novso.com!news.newsland.it!talisker.lacave.net!lacave.net!not-for-mail
From: Charles Oliver Nutter <charles.nut...@sun.com>
Newsgroups: comp.lang.ruby
Subject: Re: JRuby disabling ObjectSpace: what implications?
Date: Sun, 28 Oct 2007 16:06:32 +0900
Organization: Service de news de lacave.net
Lines: 51
Message-ID: <472434DF.2080306@sun.com>
References: <472431CC.50901@sun.com>
NNTP-Posting-Host: bristol.highgroove.com
Content-Type: text/plain; format=flowed; charset=ISO-8859-1
Content-Transfer-Encoding: 7BIT
X-Trace: talisker.lacave.net 1193555206 10421 65.111.164.187 (28 Oct 2007 07:06:46 GMT)
X-Complaints-To: abuse@lacave.net
NNTP-Posting-Date: Sun, 28 Oct 2007 07:06:46 +0000 (UTC)
X-received-from: This message has been automatically forwarded from the
   ruby-talk mailing list by a gateway at comp.lang.ruby. If it is
   SPAM, it did not originate at comp.lang.ruby. Please report the
   original sender, and not us. Thanks!
   Please see http://hypermetrics.com/rubyhacker/clrFAQ.html#tag24 too.
X-rubymirror: yes
In-Reply-To: <472431CC.50901@sun.com>
X-ML-Name: ruby-talk
X-Mail-Count: 276235
X-ruby-talk: <472434DF.2080...@sun.com>

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