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

On 6/8/2010 7:41 AM, David T. Lewis wrote:

What do the VM developers think with respect adopting the VM changes?
The immutability bit is a scarce resource. Is it OK to allocate it
for this purpose or are there likely to be other projects interested
in using it for other reasons?

Honestly, I don't thinnk the immutability bit carries its weight here. There's some fun stuff you can do with it, for sure, but outside of *extremely* specialized applications (oodbs) there will be little to no use for it. At least I don't see where you'd make use of immutability in some random app that's not a database. If it were essentially free to add it, I wouldn't mind (like I said there's fun stuff that one can do) but given that we're talking about allocating a header bit I feel that there's just not enough mileage we get out of it...

Just my random $.02.

Cheers,
 - Andreas

On 8 June 2010 19:15, Andreas Raab <[hidden email]> wrote:
>
> On 6/8/2010 7:41 AM, David T. Lewis wrote:
>>
>> What do the VM developers think with respect adopting the VM changes?
>> The immutability bit is a scarce resource. Is it OK to allocate it
>> for this purpose or are there likely to be other projects interested
>> in using it for other reasons?
>
> Honestly, I don't thinnk the immutability bit carries its weight here.
> There's some fun stuff you can do with it, for sure, but outside of
> *extremely* specialized applications (oodbs) there will be little to no use
> for it. At least I don't see where you'd make use of immutability in some
> random app that's not a database. If it were essentially free to add it, I
> wouldn't mind (like I said there's fun stuff that one can do) but given that
> we're talking about allocating a header bit I feel that there's just not
> enough mileage we get out of it...
>
> Just my random $.02.
>

my $.001
my concern is not a header bit, but introduction of its check on each
write operation,
which will slow down things.

> Cheers,
>  - Andreas
>



--
Best regards,
Igor Stasenko AKA sig.

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).

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).

Cheers,
 - Andreas

On 6/8/2010 7:41 AM, David T. Lewis wrote:

What do the VM developers think with respect adopting the VM changes?
The immutability bit is a scarce resource. Is it OK to allocate it
for this purpose or are there likely to be other projects interested
in using it for other reasons?

Oh, and one thing that I'm just realizing is that by far the biggest impact of immutability is in primitives and plugins. All primitives in all plugins must be rewritten to test for mutability of the objects they store into before this can work reliably. Ouch.

Cheers,
 - Andreas

On 9 June 2010 21:51, Andreas Raab <[hidden email]> wrote:
>
> On 6/8/2010 7:41 AM, David T. Lewis wrote:
>>
>> What do the VM developers think with respect adopting the VM changes?
>> The immutability bit is a scarce resource. Is it OK to allocate it
>> for this purpose or are there likely to be other projects interested
>> in using it for other reasons?
>
> Oh, and one thing that I'm just realizing is that by far the biggest impact
> of immutability is in primitives and plugins. All primitives in all plugins
> must be rewritten to test for mutability of the objects they store into
> before this can work reliably. Ouch.
>

Yeah. I told before, that i'm not a big fan of making VM more and more clever.
It is because 'clever' is synonym to 'complexity'.

I'd rather focus on providing immutability at language side, instead
of implementing it
primitively.

However, i am thinking, if there could be good alternatives to
immutability bit in object header.
One idea is to add this bit on a per-class basis, not on a per-instance basis.

Then VM could check immutability during a method lookup and throw
exception before entering method(s) which can mutate
an instance of such class. But then we should also divide
primitives/methods on those which can and can't
mutate the object's state, which is also a lot of work.

Checking before entering method potentially will have much less impact
on performance, because it is not so fine granular as per each write.

> Cheers,
>  - Andreas
>



--
Best regards,
Igor Stasenko AKA sig.

On 9 June 2010 22:30, Eliot Miranda <[hidden email]> wrote:
>
>
>
> On Wed, Jun 9, 2010 at 11:51 AM, Andreas Raab <[hidden email]> wrote:
>>
>> On 6/8/2010 7:41 AM, David T. Lewis wrote:
>>>
>>> What do the VM developers think with respect adopting the VM changes?
>>> The immutability bit is a scarce resource. Is it OK to allocate it
>>> for this purpose or are there likely to be other projects interested
>>> in using it for other reasons?
>>
>> Oh, and one thing that I'm just realizing is that by far the biggest impact of immutability is in primitives and plugins. All primitives in all plugins must be rewritten to test for mutability of the objects they store into before this can work reliably. Ouch.
>
> Ouch indeed.  One can at least put a check in interpreterProxy to catch attempts and cause primitives to fail.  It won't be pretty but will serve as lint for the plugins.
> Off the top of your head which plugins are likely to do writes?

There is a good primitives and bad ones.
A good ones, which use writes only to receiver. A bad ones, is those,
which doing writes to other objects (arguments/indirectly fetched
objects).
With good ones we could deal very easily, by simply modifying a code
generator to generate a write-check at the beginning of primitive. But
there is no way to deal automatically with bad ones :(

> And which of those are likely to do writes to immutables?

well, if we introduce a per-object immutability flag, then any of them
could eventually write to immutable object, isnt?

>>
>> Cheers,
>>  - Andreas
>
>
>



--
Best regards,
Igor Stasenko AKA sig.

On 9 June 2010 22:57, Eliot Miranda <[hidden email]> wrote:
>
>
>
> On Wed, Jun 9, 2010 at 12:34 PM, Igor Stasenko <[hidden email]> wrote:
>>
>> On 9 June 2010 21:51, Andreas Raab <[hidden email]> wrote:
>> >
>> > On 6/8/2010 7:41 AM, David T. Lewis wrote:
>> >>
>> >> What do the VM developers think with respect adopting the VM changes?
>> >> The immutability bit is a scarce resource. Is it OK to allocate it
>> >> for this purpose or are there likely to be other projects interested
>> >> in using it for other reasons?
>> >
>> > Oh, and one thing that I'm just realizing is that by far the biggest impact
>> > of immutability is in primitives and plugins. All primitives in all plugins
>> > must be rewritten to test for mutability of the objects they store into
>> > before this can work reliably. Ouch.
>> >
>>
>> Yeah. I told before, that i'm not a big fan of making VM more and more clever.
>> It is because 'clever' is synonym to 'complexity'.
>>
>> I'd rather focus on providing immutability at language side, instead
>> of implementing it
>> primitively.
>>
>> However, i am thinking, if there could be good alternatives to
>> immutability bit in object header.
>> One idea is to add this bit on a per-class basis, not on a per-instance basis.
>>
>> Then VM could check immutability during a method lookup and throw
>> exception before entering method(s) which can mutate
>> an instance of such class. But then we should also divide
>> primitives/methods on those which can and can't
>> mutate the object's state, which is also a lot of work.
>
> You think its cheap to scan methods for mutablity??  Remember you have to identify inst var writes not just mutating primitives like at:put:.
>
>>
>> Checking before entering method potentially will have much less impact
>> on performance, because it is not so fine granular as per each write.
>
> I don't think so.  Not without a JIT to cache the scanning of methods for mutators.

It could be done at compilation stage. No need  to scan bytecode at run time. :)
I referred to checks as 'if this method perform writes to receiver'.
But not 'if this method performs writes anywhere'.

>This scheme also only works for methods, not for code in plugins.

Sure. Plugins is another story.

> The above is speculation.  The immutability scheme I'm discussing is real and known to work in practice.
>
> 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).

I don't see this as a disadvantage.
Mutable and immutable objects are clearly having different behavior.
And in smalltalk the only way to get two objects with different
behavior is to use different classes for them. No?

> Lots of the system was affected by the change since the store string of a mutable string ends up being
>     'the immutable string literal' copy
> to get a mutable string.

Err.. not sure i understood what 'store string of a mutable string' means.

What is the point in having an immutable objects then, if you
automatically copying them at write attempt?
I don't see any gains comparing to:

' the mutable string' copy at: 1 put: $x

> 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
>     stream := '' writeStream.
> 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.

I am really interested to hear more about BrouHaHa implementation,
because i like this approach. So, i'd like to hear,
why you considering it clumsy.

> cheers,
> Eliot
>>
>> > Cheers,
>> >  - Andreas
>> >
>>
>>
>>
>> --
>> Best regards,
>> Igor Stasenko AKA sig.
>
>
>

--

Best regards,
Igor Stasenko AKA sig.