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