Hi Tobias:

On 14 Jan 2014, at 10:41, Tobias Pape <Das.Linux at gmx.de> wrote:

>> How do you implement that efficiently in RPython, or Java?
>> Keeping some kind of object table around?
> 
> Well, I have no Idea currently, but i think some #primAllObjectsDo:
> (or #primAllObjects, as it seems now) has IMHO less severe constraints
> than the #someObject/#nextObject way.
> OT is one path. Manual heap scanning another. Collecting objects from
> the roots (special objects array) a third. All these do not require 
> the #nextObject invariant.

I am just trying to think of how to implement that in the SOM VMs.
Without GC support for tracing/enumerating the objects, it’s not going to be pretty.

#someObject/#nextObject don’t make any sense for me in the long term. I want to support one form or another of parallel execution. So, if I want to offer #allObjects at all, it needs to be an atomic snapshot. Most likely with stop-the-world semantics, which is a severe burden on performance. 

And without support of the underlying platform, I think, #allObjects can’t be complete. Just thinking of how TruffleSOM works, traversing only from specialObjectsArray on, will only find part of the live heap. There are way to many important references on the Java stack, that I can’t easily access. And making them accessible, is going to cost a lot of performance even when #allObjects is never used. I think. :-/
In case you find a nice solution for RSqueak, I would be very interested.

Best regards
Stefan


-- 
Stefan Marr
INRIA Lille - Nord Europe
http://stefan-marr.de/research/