Hi Tobias,
On Tue, Jan 14, 2014 at 1:41 AM, Tobias Pape Das.Linux@gmx.de wrote:
On 13.01.2014, at 21:56, Stefan Marr smalltalk@stefan-marr.de wrote:
Hi Tobias:
On 12 Jan 2014, at 18:47, Tobias Pape Das.Linux@gmx.de wrote:
I really don’t like to say it, but it seems to me, that a VM primitive (say #primAllObjectsDo:) would be apt here. • is more easy implemented by cousin VMs (say, Potato, SqueakJS, SPy/RSqueakVM, SqueakMaxine†
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.
I've always thought that reentering the VI from a VM primitive, and hence being able to return to the VM primitive from arbitrary code executed in the block, would be problematic. It's a lot of new machinery to add for one case. Further, a GC could easily happen while executing the block.
Do you think it's easier than I'm thinking? I know for example that the VisualAge VM does something somewhat analogous for its unwind-protects (ensure: ifCurtailed:). But neither the Squeak nor the VisualWorks VMs have anything like this; primitives always run a single contiguous sequence of instructions before either returning to Smalltalk (e.g. basicNew) or resuming Smalltalk (e.g. perform:).
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.
Best -Tobias