[Vm-dev] Questions related to immutability in Cog
cunningham.cb at gmail.com
Wed Nov 11 15:47:21 UTC 2015
immutablity - and immutable bitblit?
Depending on how paranoid you want to be with the accounting, should you
also have an ungarbagecollector bit as well, so that you can't forget the
entry and re-enter it later?
On Wed, Nov 11, 2015 at 7:34 AM, Tobias Pape <Das.Linux at gmx.de> wrote:
> On 11.11.2015, at 16:21, Eliot Miranda <eliot.miranda at gmail.com> wrote:
> > Hi Tobias,
> >> On Nov 11, 2015, at 2:50 AM, Tobias Pape <Das.Linux at gmx.de> wrote:
> >> Hi all,
> >> I just want to add my 2ct to this.
> >> I'd rather like to habe the immutability bit be one-shot,
> >> non-resettable, ie, an immutable object stays that way its entire
> >> I know that conflicts with the idea of the lightweight read barrier, but
> >> I think this would be worthwhile for value classes :)
> >> Can we find a compromise here?
> > The VM is agnostic about how the upper levels of the system uses it.
> There's nothing to stop you overriding the method that sets the bit, so I
> think we can have both. Just remember that the lightweight read barrier is
> /really/ useful for persistence schemes and that's v important to typical
> industrial applications.
> I understand it is important, so maybe we should look at how make a read
> barrier a proper citizen in our town?
> My feeling now is that the on/off-immutability is primarily useful for
> that case (which is fine), but I can imagine cases where immutable
> immutability is more favourable, like Accounting: when I only can create
> but not _modify_ any object, no changes are lost (as I, for example, can
> only create newer versions of an object but not actually modify them).
> Also, when immutable objects are actually immutable, I can rely on that
> fact; nobody can change them under the hood.
> I as a VM developer then can speculate on that fact.
> Well, maybe I also want a stronger concept here (viz. Value classes), and
> be able to map identity to value equality. But I'd need immutable
> immutability, nonetheless…)
> So, I'd be more happy if we'd name the temporary immutability
> "write-locked" or so, because a lock can be lifted, actual immutability is
> I can live with a write-lock bit :D
> Best regards
> (my fingers always want to write immutablity… does anyone know that word?)
> >> Best regards
> >> -Tobias
> >>> On 10.11.2015, at 17:35, Ryan Macnak <rmacnak at gmail.com> wrote:
> >>> Hi Clement,
> >>> Per object immutability was implemented in the old, pre-Cog Newspeak
> VM (NewspeakInterpreter). It has not yet been implemented current Cog
> Newspeak VM (Stack/CoInterpreter + NewspeakVM=true), but the necessary bit
> is reserved in the object header. It was used as part of an orthogonal
> synchronization scheme to detect changed objects: mark synchronized objects
> as immutable, trap on change attempt, add to dirty list and mark as mutable
> again. A marked object is only shallowly immutable, and its instance
> variables may contain mutable objects.
> >>> Ryan
> >>> On Tue, Nov 10, 2015 at 6:17 AM, Clément Bera <bera.clement at gmail.com>
> >>> Hello everyone,
> >>> I tried to understand how immutability is implemented in the CogVM
> (NewSpeak flavor). I have some questions:
> >>> - Does it actually work and is it used ?
> >>> - Does an object being immutable means that you can't edit its
> variable fields only or that you can't either edit its instance variables ?
> Because I don't see any code checking for instance variable stores in the
> Newspeak interpreter.
> >>> - How does the immutability check works in machine code ? In the
> Newspeak interpreter there is an immutability check in #at:put: . In the
> at:put: generated by the JIT (for example
> CogObjectRepresentationFor32BitSpur) I don't see any immutability check.
> Did I miss some clever bit trick ? Does the Newspeak spur VMs use the
> #at:put: machine code version of the primitive ?
> >>> Thanks !
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Vm-dev