[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)

[Tobias Pape]

Hi Eliot
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:
1. #someObject/#nextObject
	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.
2. #primitiveAllObjectsDo:
	As Eliot points out, fragile because of the constant Image<->VM “context switch”
3. #pimitivieAllObjects
	Less fragile, tested against Eliot’s metric (time/count image->vm->image) safer than 1. or 2.

Is that right?

Best
	-Tobias

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 1665 bytes
Desc: Message signed with OpenPGP using GPGMail
Url : http://lists.squeakfoundation.org/pipermail/vm-dev/attachments/20140114/61d553e8/signature.pgp