[Vm-dev] Questions related to immutability in Cog

stephane ducasse stephane.ducasse at gmail.com
Wed Nov 11 18:18:08 UTC 2015


Thanks Colin. 
Yes I would like the same as you ;)

Stef

On 11 Nov 2015, at 18:57, Colin Putney <colin at wiresong.com> wrote:

> 
> 
> 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/7bdb17e8/attachment.htm


More information about the Vm-dev mailing list