[squeak-dev] read-only literals

Nicolas Cellier nicolas.cellier.aka.nice at gmail.com
Mon Mar 26 11:28:01 UTC 2018


Since the Compiler will decide whether literals are to be made readOnly or
not,
it's there that the preference should act, if we ever need a preference.

Mofifying a literal intentionally is a way to keep some state around at
method level.
It happened to work, but it's not a supported feature and there never were
any guaranty that such behavior would be preserved.
For example, a Compiler might as well avoid duplicating literals and share
them across CompiledMethod.

An application relying massively on such unsupported feature could use own
Compiler.
Or we could introduce kind of compiler directives in annotations like Pharo
did.
But I wonder if the complication is worth.
Aren't there many other ways to hold states?

2018-03-26 10:27 GMT+02:00 Stéphane Rollandin <lecteur at zogotounga.net>:

> As you found from running the tests, the few cases that
>> modified literals were doing it intentionally.  My guess is that more
>> read-only objects allows the VM to run a lot faster, is that right?
>> But my hope was that this capability would be provided with
>> granularity at the object-level, not necessarily the class level.
>>
>
> +1
>
> Wow, Arrays and ByteArrays too?  Magma's core Buffer classes all use
>> ByteArray's internally to represent and update their state.  Ouch!
>>
>
> +1000
>
> Magma uses previously-loaded ByteArray's and replaces their contents,
>> field by field, via ByteArray>>#uint:at:put:.  It runs this method
>> more than any other in the image -- millions and millions of times.
>> The performance of this method is very important for Magma.
>>
>
> This definitely has to be kept possible.
>
>
> - A second state would issue a warning to the transcript, while doing what
>>> the default did.
>>>
>>
>> I'm reading that and imagining a low level primitive like
>> Array>>#at:put: having a reference or signal to the Transcript that
>> runs *every single time*?  That can't be true.
>>
>
> +100
>
> In the process of raising that error, is there any danger of
>> encountering a place in the debugger code which attempted to modify
>> another Array, thus causing it to re-enter the original error-raising
>> code to raise yet another error?  It seems like a pretty low-level
>> thing to have to guard against...
>>
>
> +1
>
> I hope we are not confusing the intermal representation of objects
>> being bytes with whether those objects are literals or not.  If a
>> program sees fit to modify a "literal", techincally is not a literal,
>> but a variable, right?  Dave's case sounds like a true literal, but
>> I'm saying I have applications which update bitmap forms in real time.
>> Artists paint on SketchMorphs..  I presume you don't mean for _these_
>> cases to need to make constant copies...
>>
>
> +1000
>
>
> Instead of introducing new assumptions and breaking old code, I
>> suggest people writing which explicitly turn ON read-only'ness,  for
>> the objects they want preserving legacy expectations about Smalltalk
>> as well as the operation of legacy applications.  IMO, any
>> introduction of immutability at the class-level should be turned off
>> by default.  Make it powerful but not painful.
>>
>
> +1
>
> It would help tremendously to know what you want to accomplish and how
>> the new API works.
>>
>
> Indeed.
>
>
> Stef
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20180326/c03e9e63/attachment.html>


More information about the Squeak-dev mailing list