[Vm-dev] Re: I would not have thought I ever say that: lets have a
new primitve (was: Re: [squeak-dev] The Trunk: System-cwp.660.mcz)
eliot.miranda at gmail.com
Tue Jan 14 18:53:54 UTC 2014
On Tue, Jan 14, 2014 at 1:41 AM, Tobias Pape <Das.Linux at gmx.de> wrote:
> On 13.01.2014, at 21:56, Stefan Marr <smalltalk at stefan-marr.de> wrote:
> > Hi Tobias:
> > On 12 Jan 2014, at 18:47, Tobias Pape <Das.Linux at 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.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Vm-dev