[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