[Vm-dev] Re: Immutability, newspeak (was: Vm-dev post from jbaptiste.arnaud@gmail.com requires approval)

stephane ducasse stephane.ducasse at gmail.com
Wed Jun 9 20:14:02 UTC 2010


On Jun 9, 2010, at 7:56 PM, Andreas Raab wrote:

> On 6/9/2010 9:22 AM, Eliot Miranda wrote:
>> It's much more general purpose than OODBs.  Immutable literals and
>> immutable numerics are very nice to have.  Lazy copying in mutable
>> structures is useful in general.  A number of other dialects have an
>> immutability bit and it has carried its weight there.
> 
> In what kinds of applications?
> 
> I have two major concerns about your arguments. One is that any kind of "lazy copying" relies on a fast become which we don't have. So this entire line of applications is probably moot as far as I can tell (correct me if I'm wrong but I don't see how lazy copying can work without fast become).
> 
> Secondly, for concurrency uses (which is the aspect that interests me most) the "kind" of immutability proposed here is wrong. What's proposed here is a one-level immutability which is really more a kind of write barrier, i.e., it gets turned on, then it gets caught, then it gets turned off, and is written to anyway. For concurrency, you need immutability that is a) transitive (i.e., freezes an entire object graph) and b) irreversible (i.e., sealing the object graph).

JB implemented that as the first part of its phd (we will present a paper at tools this year): A control flow oriented readyonly propagation so a complete graph of objects get readonly but we played with the possibility to have this behavior from a reference perspective: two references to the same object can be one readyonly and the other not. Now we should build more examples. He used the place of the immutability for that but we thought that immutability would be a good facilities to have in other contexts so this is why he extracted it from newspeak. 


> In terms of general applicability, I would much prefer the latter (it matters not for immutable literals which kind is used) but I don't see how these different forms of immutability can be reconciled without yet another header bit. But if you're in favor of one, you can hardly be against the other, no?
> 
> So should we add two header bits for immutability instead of one? What concerns me here is that any use of immutability appears to be requiring yet another header bit - a sign that we thoroughly do not understand what immutability is and how it should be implemented. Thus my feeling that throwing header bits at the problem is the wrong direction.
> 
>> In short, scarce resource issues such as header bits are solvable (by
>> reimplementing to make more available), immutability is much more
>> generally useful than OODB interfaces, so (at least form me) this is
>> good use of something lying fallow.
> 
> I'm not strongly opposed to it but header bits *are* a scarce resource so their allocation should be done carefully as well as the choice of semantics. I can say for sure that I would feel *much* better if there was a customer who'd say "yes, this is exactly what I need, the semantics is precisely right for what I need it for" instead of just "Oooooohhhh, immutability, cooooool" (which is all I'm hearing).

I would really like to know what VW benefitted from it. I imagine a bit but I would really like to be convinced because may be 
we should redesign some librairies to take advantage of this behavior. 

> Cheers,
>  - Andreas



More information about the Vm-dev mailing list