2008/7/2 Eliot Miranda <eliot.miranda at gmail.com>:
>
>
> On Tue, Jul 1, 2008 at 1:47 PM, <bryce at kampjes.demon.co.uk> wrote:
>>
>> Igor Stasenko writes:
>>  > 2008/6/30 Peter William Lount <peter at smalltalk.org>:
>>  > > Hi,
>>  > > Speed is always fun - fast programs and fast cars that is.
>>  > >
>>  >
>>  > Moreover, if you looking for speed, just take a look at Huemul
>> Smalltalk :)
>>
>> You could also look at Exupery itself, I think Exupery is about as
>> fast as Huemul. Huemul was much faster until it got a few extra
>> language features that cost performance. Exupery's been through the
>> same loop, fast, add features, then add more optimisations to regain
>> the speed.
>>
>> Bryce
>>
>> P.S. That's one reason I don't like the idea of a write protect bit in
>> the object header. It adds yet another thing to check for every single
>> write into an object. Small costs add up on common basic operations.
>
> Actually one can be clever about this.  yes one has to check for inst var
> assignment.  But for at:put: one can fold the check into other activities.
>  For example, in my VisualWorks implementation the write-protect bit was put
> very close to and more significant than the size field in the object header.
>
> An at:put: has to extract the size of the array for the bounds check.  The
> size field might indicate an overflow size (for large arrays their size
> doesn't fit in the header size field and requires an additional word in
> front of the header to store the actual size.  The overflow is indicated by
> the size field being at its maximum value or somethign similar).
>
> So in at:put: code masks off the size field and the write-protect bit so
> that when the check is made for an overflow size a write-protected object
> appears to have an overflow size.  So the check for write-protect is done
> only in the arm that fetches the overflow size.  This makes the test free
> for most array accesses since most arrays are small enough to not need an
> overflow size (at least in VW).
>
>> Write protection could be implemented using similar tricks to the
>> write barrier. Then send optimisation will help reduce the costs when
>> it's used. When it's not used, there's no cost.
>
> I don't understand this.  Can you explain the write-barrier tricks and the
> send optimization that eliminates them?
>
> I think per-object write-protection is very useful.  Its very useful for
> read-only literals, OODBs, proxies (distributed objects), debugging, etc.
>  Amongst Smalltalks I think VisualAge had it first and I did it for VW round
> about 2002.  I did it again for Squeak at Cadence.  In both the VW and
> Squeak cases the performance degradation was less than 5% for standard
> benchmarks.  Its cheap enough not to be noticed and there's lots more fat in
> the Squeak VM one can cut to more than regain performance.
>
> So unlike, say, named primitives for the core primitives, this is something
> I am in favour of.  It is a cost well worth paying for the added
> functionality.
>
>
>

Well, i don't think that write-protect (AKA immutable bit) is of great
importance.
There are simple and fool prof concept, used in E:
- do not expose critical resources outside your model.
Then, since you can't have reference to object(s) you may want to
modify, you can't do any harm.

Then in 99% cases the check is redundant.

-- 
Best regards,
Igor Stasenko AKA sig.