[Vm-dev] Re: [Pharo-dev] Should literals be immutable ?

Eliot Miranda eliot.miranda at gmail.com
Mon Oct 27 16:07:17 UTC 2014


Hi Clément,

     IMO literals should be immutable all the time, and IMO the best way is via a per-object isImmutable bit.  We implemented this for VW in 7.0 and it was a positive experience.

I've implemented the "create an immutable subclass for each literal class" and it has lots of problems (thing printString or storeString having to produce something like 'an immutable string' asMutableString for a normal string).

The per-object bit has other uses too.  Object databases such as GemStone can use it to make write-through scheme efficient.  

The only problem we had was dealing with broken user code that was depending on mutable literals.  This is of course a bug, but folks thought we shouldn't just break user code so Alan Knight provided a system setting that write a warning to the transcript and updated the literal instead if raising an error.  That's easy to do, if IMO dubious.  Fixing the code is as easy as sending copy to the literal in question, the copy being mutable.

Now I implemented the per-object bit for the Newspeak interpreter WM so you'll find lots of the necessary work is there waiting to be ported to the Stack and Cog VMs.  I've not had the time to implement the JIT support to catch inst var and at:put: writes to immutables.  But it shouldn't be too much work.  Volunteers?

Eliot (phone)

On Oct 27, 2014, at 8:22 AM, Clément Bera <bera.clement at gmail.com> wrote:

> Hey guys,
> 
> I was discussing about methods like that with Marcus:
> 
> MyClass>>foo
> 	#(false) first 
> 		ifFalse: [ 
> 			'first call since compilation' logCr. 
> 			#(false) at: 1 put: true ]
> 		ifTrue: [ 'other calls' logCr ]
> 
> DoIt:
> 4 timesRepeat: [MyClass new foo ]
> 
> Transcript:
> 'first call since compilation'
> 'other calls'
> 'other calls'
> 'other calls'
> 
> In the sista image/VM, we are most probably going with Eliot to implement a slow path when you edit the literal of a method (deoptimizing the method) so we can consider that the literals are immutable in the generic case (and if it's not true, execution falls back to a slow path).
> 
> But I was thinking, does it worth it to implement the slow path ? 
> Couldn't we just put literals as immutable all the time ? 
> The methods as the one shown before would not work any more. But does someone use it ?
> 
> ...
> 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/vm-dev/attachments/20141027/1e7c7e67/attachment.htm


More information about the Vm-dev mailing list