[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)
Das.Linux at gmx.de
Tue Jan 14 20:20:26 UTC 2014
On 14.01.2014, at 19:53, Eliot Miranda <eliot.miranda at gmail.com> wrote:
> 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:).
So, i think we have 3 levels of VM-problematic here:
this dualism, split in two methods, requires most from the vm: perhaps a certain memory layout or the emulation thereof
Fragile in every possible way, as both can be used individually, apart from #allObjectsDo:, so impolementors have to be aware of that.
As Eliot points out, fragile because of the constant Image<->VM “context switch”
Less fragile, tested against Eliot’s metric (time/count image->vm->image) safer than 1. or 2.
Is that right?
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 1665 bytes
Desc: Message signed with OpenPGP using GPGMail
Url : http://lists.squeakfoundation.org/pipermail/vm-dev/attachments/20140114/61d553e8/signature.pgp
More information about the Vm-dev