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

Eliot Miranda eliot.miranda at gmail.com
Mon Oct 27 16:23:31 UTC 2014


On Mon, Oct 27, 2014 at 9:19 AM, Levente Uzonyi <leves at elte.hu> wrote:

> On Mon, 27 Oct 2014, Clément Bera 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 ?
>>
>
> This method was used in Seaside (or some Seaside extension) to cache the
> contents of files in methods.
>
> By the way, how would you ensure immutability?
>

See my message earlier in the thread.  Via a per-object isImmutable bit.



> I mean, how would you prevent something like this?
>
> MyClass >> foo
>
>         ^#('placeHolder')
>
> And then
>
> (((MyClass >> #foo) literalAt: 1) at: 1) becomeForward: Object new
>
>
> Levente
>
> P.S.: why isn't this on the vm-dev list?
>
>
>> ...
>>
>>
>>


-- 
best,
Eliot
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20141027/d80515e5/attachment.htm


More information about the Squeak-dev mailing list