From: Ken Bloom <kbloom@...>
Date: 2008-10-30T04:07:38+09:00
Subject: [ruby-core:19616] Re: GC thought

On Wed, 29 Oct 2008 20:24:05 +0900, Charles Oliver Nutter wrote:

> Hongli Lai wrote:
>> Robert Klemme wrote:
>>> ObjectSpace does create some issues for JRuby IIRC, so maybe we should
>>> consider whether we can get rid of it without too many disadvantages.
>> 
>> There's at least one important use case for ObjectSpace: closing all
>> open IO objects. This is very important for daemonizing a process.
> ...
>> However, walking ObjectSpace is quite inefficient. I wouldn't mind
>> getting rid of ObjectSpace if an alternative for closing all IO objects
>> is provided.
> 
> ObjectSpace is more than just inefficient...it and features like it are
> holding back the standard Ruby implementation, since they impose
> concurrency, memory layout, and GC limitations. That's why each_object
> is not fully-functional in JRuby by default...because we're running on a
> GC and memory model incompatible with arbitrarily walking the heap.
> 
> In JRuby, we also want to be able to shut down all IO objects, since we
> do caching at a Java level rather than through C APIs (FILE*). So we
> keep a weak list of all IO objects and run through it as needed.
> Maintaining such a list in any implementation would be trivial, and an
> API could be provided for programmatically accessing it.
> 
> In a similar fashion, we track subclasses in weak lists attached to each
> class. The lists are lazily allocated, so they don't exist unless there
> are subclasses. But they allow us to support each_object(Class)
> trivially by walking the live class hierarchy directly.
> 
> I suppose the bottom line I want to convey is that almost all the
> practical uses of ObjectSpace (outside of debugging and toy uses, for
> which nobody cares about performance) can be implemented in other ways
> that don't impose limitations on the system. As I've advocated before
> I'll advocate again: ObjectSpace should go.
> 
> - Charlie

ObjectSpace shouldn't go.

Last time I saw this discussion, you mentioned that it wasn't a problem 
(and was in fact important) to support 
ObjectSpace.{define,add,call,undefine,remove}_finalizer, and how 
ObjectSpace._id2ref is still supportable, and clearly 
ObjectSpace.garbage_collect is identical to GC.start. And I saw people 
getting very confused over this issue when you discussed it for JRuby.

It's each_object that you want to get rid of, so say that instead.

-- 
Chanoch (Ken) Bloom. PhD candidate. Linguistic Cognition Laboratory.
Department of Computer Science. Illinois Institute of Technology.
http://www.iit.edu/~kbloom1/