[Vm-dev] [Pharo-project] Plan/discussion/communication around new object format

Igor Stasenko siguctua at gmail.com
Wed Jun 13 03:27:04 UTC 2012


On 11 June 2012 23:46, Colin Putney <colin at wiresong.com> wrote:
>
> On Mon, Jun 11, 2012 at 2:42 PM, Chris Muller <asqueaker at gmail.com> wrote:
>>
>>> if you remember i said before, that i don't like immutability enforced
>>> through VM contract.
>>>
>>> imagine two frameworks, using immutability flag for their own
>>> purposes, and contending for ownership
>>> of same object(s)..
>>>
>>> IMO, there are other , better, solutions to that but i'm not going to
>>> go in details...
>>
>> I totally agree with you here, too.  An immutability-bit is like
>> static-typing, or RDBMS RI, or "truly private" methods (to which I'm
>> also opposed).  Each of those enforces some past notion about that
>> object/method/whatever on the present, even until it should no longer
>> be the case -- at which point you simply go into the "meta settings"
>> and turn it off because it got in your way.
>>
>> Probably better to just avoid all that in the first place.
>
> Ok, what if we call it a "fast write-barrier provided by the VM".
> Would that change your view? Igor?
>

The problem is that it is not nearly as fast:
 - at every memory write you have to check this flag, even if it is not used
anywhere by anything at language side, you will still pay the price.

I would understand if we want to have a dedicated VM where this flag
will serve only single purpose to support a specific software (like
OODB) which is the only
user of this flag.

Another (open) question, is how to deal with immutability in presence
of  become, i.e.:

mutableCopy := immutableObject shallowCopy.
immutableObject becomeForward: mutableCopy.

such kind of things making immutability useless for protecting some
critical parts of object memory,
like preventing modification of compiled method literals:
  yes you cannot change the immutable object, but you can replace all
pointers to it with it's own mutable copy, which is equivalent to
making it mutable again.

-- 
Best regards,
Igor Stasenko.


More information about the Vm-dev mailing list