[Vm-dev] Questions related to immutability in Cog

[Colin Putney]

On Wed, Nov 11, 2015 at 7:34 AM, Tobias Pape <Das.Linux at gmx.de> wrote:


> 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
> perpetual…
> I can live with a write-lock bit :D


Yeah, I'd like to see this too. I think there are 3 interesting cases here:


Write Barrier

This what VW (mistakenly) calls "immutability". As Eliot described up
thread, each object has a bit can be set to trap writes. When the bit is
set, any primitive that modifies the object fails, and any bytecode that
modifies the object instead sends #attemptToWrite:atIndex:. It lets writes
be intercepted by image-level code, which is useful for external
persistence mechanisms, eg Gemstone.

An alternate implementation might be to just set a bit whenever a write
operation occurs, and then have primitives for testing and clearing the bit
explicitly. Persistence mechanisms tend to just want to know when an object
has changed, and don't really need to intercept the change before it
happens, so this would be sufficient.


Read Barrier

Similar to the write barrier, but for reads. Again, I could imagine two
ways of doing it. One would be to trap reads by sending something like
#attemptToRead:atIndex: and then having the read complete with whatever
that method returns. Another would be to set a bit on every read, and have
primitives for testing and clearing it.

Persistence code typically creates stub objects that "fault" when they
receive a message, pull in data from outside the image, then become the
appropriate object. Having a read barrier of the #attemptToRead:atIndex:
sort would let the object be created with the correct class, and then
populated with state when it's actually needed.

The other implementation with a bit that keeps track of which objects have
been read would be useful for other cases. One example I ran into is in
Altitude. Managing state is the essence of web applications, and getting
good performance and scalability requires caching of state at several
different levels of the system. One thing I was trying to do was generate
ETag headers based on which model objects were read during the rendering of
a particular resource, so that the ETag values would change iff the state
of the model objects that affected the rendered data changed.

One might do the same in the case of an IDE, for example. The visual state
of a given browser window depends on the state of a certain set of objects
in the image - classes, methods, organizers etc. By knowing *which* objects
contributed to a given view, we can know that we have to update the view
when, and only when, those objects change.


Immutability

True immutability, not the VW version. I'd like to see this implemented as
a property of classes. Immutable classes create instances via a new
primitive that instantiates and initializes the object in one step. After
that, the object cannot be modified. Having that invariant would be useful
both in the VM and in the image.

In the VM, we'd be free to take liberties with object identity. As Tobias
mentioned we could have "value" object that get copied rather than passed
as references whenever that makes sense. We might inline value objects
within other objects to avoid chasing pointers. We might reorganize arrays
of value objects into arrays of their individual fields where that would be
useful for performance. The GC might merge all references to identical
value objects during heap compaction.

In the image, we could share value objects between processes without
worrying about synchronization. We could copy them over the network to make
remote messaging more efficient. Persistence frameworks could read and
write clusters of value objects along with their owning entities, rather
than faulting them in one at a time.

Even for more prosaic applications, immutable objects are pretty useful. I
find I often create pseudo-immutable classes, where the immutability isn't
really enforced, but it happens that the only method that modifies an
object's state is the initializer. Having that enforced by the VM would be
create, and would let the image-level tools be smart about it as well. A
browser might warn you if you accept a method that does a write on an
immutable class.


Anyway, I'm not trying to set the agenda for VM development, but could we
please avoid Cincom's naming mistake and keep open the possibility of true
immutability?

-Colin
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/vm-dev/attachments/20151111/1e5d2a3a/attachment-0001.htm