<br><br><div class="gmail_quote">On Thu, Jul 3, 2008 at 2:56 PM, <<a href="mailto:bryce@kampjes.demon.co.uk">bryce@kampjes.demon.co.uk</a>> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div class="Ih2E3d">Eliot Miranda writes:<br>
> > P.S. That's one reason I don't like the idea of a write protect bit in<br>
> > the object header. It adds yet another thing to check for every single<br>
> > write into an object. Small costs add up on common basic operations.<br>
><br>
><br>
> Actually one can be clever about this. yes one has to check for inst var<br>
> assignment. But for at:put: one can fold the check into other activities.<br>
> For example, in my VisualWorks implementation the write-protect bit was put<br>
> very close to and more significant than the size field in the object header.<br>
<br>
</div><snip, neat optimisation><br>
<div class="Ih2E3d"><br>
> > Write protection could be implemented using similar tricks to the<br>
> > write barrier. Then send optimisation will help reduce the costs when<br>
> > it's used. When it's not used, there's no cost.<br>
><br>
><br>
> I don't understand this. Can you explain the write-barrier tricks and the<br>
> send optimization that eliminates them?<br>
<br>
</div>Automatically create a new hidden subclass of the class that acts<br>
appropriately for every write. The write protection can then be<br>
encoded in the class. The only overhead is that required by dynamic<br>
dispatch which we're already paying for.</blockquote><div><br>Ah, ok. This doesn't work in general. e.g. one can't turn on immutablity in the middle of a method that assigns to inst vars. The method in the subclass would need to be different and mapping pcs at runtime is, uh, decidely nontrivial. It works for access to arrays but not to objects in general. <br>
<br><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"><div class="Ih2E3d"> > I think per-object write-protection is very useful. Its very useful for<br>
> read-only literals, OODBs, proxies (distributed objects), debugging, etc.<br>
> Amongst Smalltalks I think VisualAge had it first and I did it for VW round<br>
> about 2002. I did it again for Squeak at Cadence. In both the VW and<br>
> Squeak cases the performance degradation was less than 5% for standard<br>
> benchmarks. Its cheap enough not to be noticed and there's lots more fat in<br>
> the Squeak VM one can cut to more than regain performance.<br>
><br>
> So unlike, say, named primitives for the core primitives, this is something<br>
> I am in favour of. It is a cost well worth paying for the added<br>
> functionality.<br>
<br>
</div>And when we're twice as fast as VisualWorks is now it'll be a 10%<br>
overhead. Twice as fast as VisualWorks is the original goal for<br>
Exupery.<br></blockquote><div><br>Where are you on that?<br> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">Immutability or change tracking can be provided more efficiently purely<br>
inside the image when it's needed.<br>
<br>
Bryce<br>
<br>
</blockquote></div><br>