<br><br><div class="gmail_quote">On Wed, Jun 9, 2010 at 12:34 PM, Igor Stasenko <span dir="ltr"><<a href="mailto:siguctua@gmail.com">siguctua@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div><div></div><div class="h5"><br>
On 9 June 2010 21:51, Andreas Raab <<a href="mailto:andreas.raab@gmx.de">andreas.raab@gmx.de</a>> wrote:<br>
><br>
> On 6/8/2010 7:41 AM, David T. Lewis wrote:<br>
>><br>
>> What do the VM developers think with respect adopting the VM changes?<br>
>> The immutability bit is a scarce resource. Is it OK to allocate it<br>
>> for this purpose or are there likely to be other projects interested<br>
>> in using it for other reasons?<br>
><br>
> Oh, and one thing that I'm just realizing is that by far the biggest impact<br>
> of immutability is in primitives and plugins. All primitives in all plugins<br>
> must be rewritten to test for mutability of the objects they store into<br>
> before this can work reliably. Ouch.<br>
><br>
<br>
</div></div>Yeah. I told before, that i'm not a big fan of making VM more and more clever.<br>
It is because 'clever' is synonym to 'complexity'.<br>
<br>
I'd rather focus on providing immutability at language side, instead<br>
of implementing it<br>
primitively.<br>
<br>
However, i am thinking, if there could be good alternatives to<br>
immutability bit in object header.<br>
One idea is to add this bit on a per-class basis, not on a per-instance basis.<br>
<br>
Then VM could check immutability during a method lookup and throw<br>
exception before entering method(s) which can mutate<br>
an instance of such class. But then we should also divide<br>
primitives/methods on those which can and can't<br>
mutate the object's state, which is also a lot of work.<br></blockquote><div><br></div><div>You think its cheap to scan methods for mutablity?? Remember you have to identify inst var writes not just mutating primitives like at:put:.</div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">Checking before entering method potentially will have much less impact<br>
on performance, because it is not so fine granular as per each write.<br></blockquote><div><br></div><div>I don't think so. Not without a JIT to cache the scanning of methods for mutators. This scheme also only works for methods, not for code in plugins.</div>
<div><br></div><div>The above is speculation. The immutability scheme I'm discussing is real and known to work in practice.</div><div><br></div><div><br></div><div>BTW, I implemented a per-class scheme ages ago in above BrouHaHa (in a Smalltalk-80 v2.3 derived image) to provide immutable literals. It worked badly for literals since 'foo' class ~~ 'foo' copy class (one needs an ImmutableByteString class and a ByteString class for every class one wants to make immutable). Lots of the system was affected by the change since the store string of a mutable string ends up being</div>
<div> 'the immutable string literal' copy</div><div>to get a mutable string.</div><div><br></div><div>Our experience with VisualWorks was different. Lots of methods had to be changed because they were attempting to update immutable literals. There were lots of </div>
<div> stream := '' writeStream.</div><div>throughout the system which had not been noticed. But unlike the BrouHaHa experience the changes only affected violations of immutability. In BrouHaHa the changes were due to trying to accommodate the clumsy class-based scheme.</div>
<div><br></div><div>cheers,</div><div>Eliot</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div><div></div><div class="h5"><br>
> Cheers,<br>
> - Andreas<br>
><br>
<br>
<br>
<br>
--<br>
Best regards,<br>
Igor Stasenko AKA sig.<br>
</div></div></blockquote></div><br>