[Vm-dev] Re: [Pharo-dev] Immutability in the VM - is it hard?

[Eliot Miranda]

Hi Aaron,


On Sun, May 4, 2014 at 8:40 AM, Aaron Rosenzweig <aaron at chatnbike.com>wrote:

> Hello,
>
> Why is the concept of “immutability” special to VisualWorks? Is it
> something hard to add to other Smalltalk dialects such as Pharo or are
> there other reasons for not having it?
>

First, the concept isn't special to VisualWorks.  The VisualAge VM had it
before VW (AFAIA VA had it first) and I implemented it for VisualWorks in
the early 2000's to allow the GemStone implementation on VisualWorks to be
as simple as it is on VisualAge.

Second, I implemented immutability for the Newspeak Interpreter VM, a
modified Squeak interpreter VM, in 2007 and you'll find that code in the
VMMaker.oscog package in the NewspeakInterpreter class.

So no, it's not hard to add.  It's simply hard to find the time to port the
code from the NewspeakInterpreter VM to the Cog VM.  Volunteers are
encouraged to have a go and I'm very happy to give advice.  Right now my
priority is getting the 32-bit Spur port deployed (and having implemented a
functional compaction algorithm this last week I can now do so).


> When I read the docs for the GOODS database client it says the following:
>
> “The GOODS client uses this immutability support for change detection.”
>
> It goes on to say that this is only for VisualWorks. For Pharo it says
> that it is generally slow to commit changes because the client to the OODB
> has to spent extra time detecting change detection. I guess for VisualWorks
> it is basically “free” to detect a change in an object.
>

It's pretty cheap, but not quite free.  It's quite simple.  When
immutability is implemented, the system uses a bit in the object header as
a per-object immutability flag, and checks the bit before every assignment.
 An attempt to assign an inst var in an immutable object causes a send-back
of attemptToAssign: theValue withIndex: instVarIndex to the immutable
object being assigned.  An attempt to assign an immutable object in a
primitive causes that primitive to fail with a PrimErrNoModification
primitive failure code.  IIRC the VW VM slowed by about 6%
when immutability was implemented.  I hope that on modern machines the
slowdown would be even less, but the extra read of the object header during
inst var assignment is a significant cost.  The cost for primitives is much
less because bounds checking implies a read of the object header to
determine an object's size anyway.

HTH

and pardon me for asking that in future you cc vm-dev for VM-related
discussions.  Thanks.


> Thank you,*Aaron Rosenzweig* / Chat 'n Bike <http://www.chatnbike.com>
> *e:*  aaron at chatnbike.com  *t:*  (301) 956-2319   [image: Chat 'n Bike]  [image:
> Chat 'n Bike]
>
-- 
best,
Eliot
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/vm-dev/attachments/20140504/e2835222/attachment.htm