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 eliot.miranda at gmail.com
Tue Jan 14 18:53:54 UTC 2014


Hi Tobias,


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.
>
> Best
>         -Tobias
>
-- 
best,
Eliot
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20140114/6347a047/attachment.htm


More information about the Squeak-dev mailing list