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)
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
Hi Eliot On 14.01.2014, at 19:53, Eliot Miranda eliot.miranda@gmail.com wrote:
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:).
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
?
thx,
tty
cuz it is alongside the Cogit (JIT), cooperating with it to execute Smalltalk, and cuz Cog starts with c o.
Eliot (phone)
On Jan 14, 2014, at 4:25 PM, gettimothy gettimothy@zoho.com wrote:
?
thx,
tty
vm-dev@lists.squeakfoundation.org
-
Eliot Miranda -
gettimothy -
Tobias Pape