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

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
34 messages Options
12
Reply | Threaded
Open this post in threaded view
|

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

David T. Lewis
 
The following message to vm-dev was blocked due to size of the attachments
(3 MB) so I am forwarding the message text directly to the list without
attachments.

Jean Baptiste,

If you can make the ImageSide.zip and VMMaker-jb.172.mcz files available
from a web site, that would be helpful.

Thanks,

Dave

----- Forwarded message from [hidden email] -----

From: Jean Baptiste Arnaud <[hidden email]>
Subject: Immutability, newspeak
Date: Mon, 7 Jun 2010 13:31:44 +0200
To: Squeak Virtual Machine Development Discussion
        <[hidden email]>
X-Mailer: Apple Mail (2.1078)

Hi,
I extract the code of The immutability bit from Newspeak.
I have do a first step :

- I have the same test from Newspeak image :
                - Pass the test as Newspeak image.

Use the same bit and the same primitive numbers from Newspeak.
Do it from a Pharo image:

Pharo-1.0
Latest update: #10517
on a VMMaker 170 version (the code have Pharo patch and Alien-VMMaker-Support).

I send the code if that interest some people.
You can give me feedback, recommendation.

The VMMaker Change




All other change of the image.




Regard
Jean Baptiste Arnaud
[hidden email]


Reply | Threaded
Open this post in threaded view
|

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

Jean Baptiste Arnaud

Hi,
I extract the code of The immutability bit from Newspeak.
I have do a first step :

- I have the same test from Newspeak image :
                - Pass the test as Newspeak image.

Use the same bit and the same primitive numbers from Newspeak.
Do it from a Pharo image:

Pharo-1.0
Latest update: #10517
on a VMMaker 170 version (the code have Pharo patch and Alien-VMMaker-Support).

I send the code if that interest some people.
You can give me feedback, recommendation.

The VMMaker
http://dl.dropbox.com/u/7879914/Immutability/VMMaker-jb.172.mcz

Image Side
http://dl.dropbox.com/u/7879914/Immutability/ImageSide.zip


On Jun 8, 2010, at 1:43 AM, David T. Lewis wrote:

> The following message to vm-dev was blocked due to size of the attachments
> (3 MB) so I am forwarding the message text directly to the list without
> attachments.
>
> Jean Baptiste,
>
> If you can make the ImageSide.zip and VMMaker-jb.172.mcz files available
> from a web site, that would be helpful.
>
> Thanks,
>
> Dave
>
> ----- Forwarded message from [hidden email] -----
>
> From: Jean Baptiste Arnaud <[hidden email]>
> Subject: Immutability, newspeak
> Date: Mon, 7 Jun 2010 13:31:44 +0200
> To: Squeak Virtual Machine Development Discussion
> <[hidden email]>
> X-Mailer: Apple Mail (2.1078)
>
> Hi,
> I extract the code of The immutability bit from Newspeak.
> I have do a first step :
>
> - I have the same test from Newspeak image :
> - Pass the test as Newspeak image.
>
> Use the same bit and the same primitive numbers from Newspeak.
> Do it from a Pharo image:
>
> Pharo-1.0
> Latest update: #10517
> on a VMMaker 170 version (the code have Pharo patch and Alien-VMMaker-Support).
>
> I send the code if that interest some people.
> You can give me feedback, recommendation.
>
> The VMMaker Change
>
>
>
>
> All other change of the image.
>
>
>
>
> Regard
> Jean Baptiste Arnaud
> [hidden email]
>
>

Regard
Jean Baptiste Arnaud
[hidden email]




Reply | Threaded
Open this post in threaded view
|

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

David T. Lewis
 
On Tue, Jun 08, 2010 at 11:01:28AM +0200, Jean Baptiste Arnaud wrote:

>
> Hi,
> I extract the code of The immutability bit from Newspeak.
> I have do a first step :
>
> - I have the same test from Newspeak image :
> - Pass the test as Newspeak image.
>
> Use the same bit and the same primitive numbers from Newspeak.
> Do it from a Pharo image:
>
> Pharo-1.0
> Latest update: #10517
> on a VMMaker 170 version (the code have Pharo patch and Alien-VMMaker-Support).
>
> I send the code if that interest some people.
> You can give me feedback, recommendation.
>
> The VMMaker
> http://dl.dropbox.com/u/7879914/Immutability/VMMaker-jb.172.mcz
>
> Image Side
> http://dl.dropbox.com/u/7879914/Immutability/ImageSide.zip

Thanks!

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?

Dave
 
Reply | Threaded
Open this post in threaded view
|

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

Andreas.Raab
 
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
Reply | Threaded
Open this post in threaded view
|

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

stephane ducasse-2

Andreas

This is true that having this free bit is nice for experimenting.  Now the immutability bit would be really good to
build immutable strings and other data types. We could for example ensure that string literal are not modified even if stored
in the literal frame. When we see the current trends in languages (erlang, newspeak...) it would be good to have it
but this is also true that we should build a real case before that so we are also in a bootstrap loop. Last time I checked point
and rectangle and they are functional by design so I'm curious to know what we could gain to make them immutable.

Now eliot mentioned that he will get rid of compact class so we could get more bits.
Note that jean-baptiste did this work because eliot mentioned that we should extract it from newspeak if we want to get a chance
to have it in squeak/pharo.

Stef

On Jun 8, 2010, at 6:15 PM, Andreas Raab 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.
>
> Cheers,
>  - Andreas

Reply | Threaded
Open this post in threaded view
|

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

Eliot Miranda-2
In reply to this post by Andreas.Raab
 


On Tue, Jun 8, 2010 at 9:15 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?

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

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. The header bit might as well be used for something useful.  The argument that it's scarce resource can be used against any and all uses, and as has been mentioned elsewhere in the thread, that should be a relatively short-term limitation anyway.  

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.

best
Eliot


Just my random $.02.

Cheers,
 - Andreas

Reply | Threaded
Open this post in threaded view
|

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

Igor Stasenko
In reply to this post by Andreas.Raab

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.
Reply | Threaded
Open this post in threaded view
|

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

Eliot Miranda-2
 


On Wed, Jun 9, 2010 at 10:25 AM, Igor Stasenko <[hidden email]> wrote:

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.

My experience in VisualWorks and Newspeak was that the total cost was in of the order of a < 5% slowdown over a broad range of benchmarks.  The cost is this small because at least for pointer writes (which includes inst var writes) there is already an expensive store check and adding a few more instructions which access data header data that is almost always already in the cache is a small additional cost.  The relative cost is also small for array writes because of the cost of the bounds check.

best
Eliot

P.S. with clever coding the check can be folded into the bounds check for pointer array writes.  The trick is to include the immutable bit into the inst size calculation so that compact header immutable arrays look as if they have no indexable fields because including the immutable bit makes it look like they have a lot of named inst vars.


> Cheers,
>  - Andreas
>



--
Best regards,
Igor Stasenko AKA sig.

Reply | Threaded
Open this post in threaded view
|

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

Andreas.Raab
In reply to this post by Eliot Miranda-2
 
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
Reply | Threaded
Open this post in threaded view
|

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

johnmci
In reply to this post by Igor Stasenko
 
In my looking at performance issues like this the current generatios  
of CPUs just hide that extra instruction and the CPu runs a bit  
hotter. What should happen is some macrobenchmark be run with without  
the feature otherwise we are guessing

Sent from my iPhone

On 2010-06-09, at 10:25, Igor Stasenko <[hidden email]> wrote:

>
> 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.
Reply | Threaded
Open this post in threaded view
|

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

Eliot Miranda-2
In reply to this post by Andreas.Raab
 


On Wed, Jun 9, 2010 at 10:56 AM, Andreas Raab <[hidden email]> 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).

Here's a sketch of how to do this without a fast become.  Any client of a lazily copied data structure puts an exception handler at some point around their ruse of the data structure.  They catch the immutability exception and coordinate with the data structure to update their reference to the data to a copy  So instead of the data structure managing things internally there's some sharing.  Something like

    [sink store: self data]
        on: NoModificationError
        do: [:ex|
              (sink ownsImmutableIn: ex) ifFalse:
                  [ex pass].
              sink := sink copyOnWrite ex.
              ex retry]

THis kind of linkage is clumsy, which is why one constructs a per-object policy scheme where on can attach actions to attempts to update specific objects.  In this approach sink (and any necessary substructure) would have been registered with some kind of policy object (an immutability manager) that would take case of sending messages to the client to get it to update its reference to sink and retry the operation.  So with prior registration (which could be folded into the instance creation code for sink) the api then becomes

    sink store: data

with the exception handling managed in the background.

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

That's fine and one can build deep immutability above the shallow immutability that the immutable bit provides.  All one needs to do is traverse the object graph, setting the immutability bit.  You might want to carefully control unsetting the immutability bit so that its hard to inadvertently turn off immutability in substructure to get b).  But in any case turning off immutability on something that is immutable is never  something that's done lightly.

I have at least discussed using shallow immutability to implement deep immutability with Gilad for Newspeak and he hasn't yet said it can't be done this way.

Note tat deep immutability is a tricky issue.  Is the class of a deeply immutable object immutable or can one still add methods to it?  What happens (with both shallow and deep immutability) if one tries to add an instance variable to a class that has immutable instances? What if one wants a mostly deeply immutable data structure that contains e.g. a mutable query cache that memos the most recent N results of some expensive query?  Exactly what parts of a data structure should be immutable when is typically application and data structure dependent and some blanket deep immutability scheme in the VM is likely to be too inflexible.  A simple per-object bit which has simple semantics and can serve in many different uses is flexible enough, at least if 15 years of experience with VisualAge and 10 years of experience with VW is meaningful.

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?

I don't see that at the VM level two header bits gains you anything.  You're talking about a policy issue above the VM.  One bit is all the VM needs to implement the necessary mechanism.   Policy at the image level can then manage the immutability bit to provide myriad schemes.
 

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.

Agreed.  I'm not proposing throwing bits at the problem.  One bit's enough.  Its up to the image level to design a good framework around the basic VM facility, and that's been done already.

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

While some people might be saying "it's cool" I hear the GemStone folks saying "we much prefer using the immutability bit than rewriting code.  the immutability bit has worked much better in practice", and GemStone has plenty of customers who don't have to worry about the issue because GemStone has done all the work for them. I don't hear anyone from VisualAge and VisualWorks saying "It's a bad idea, it's had a deleterious effect on performance".  But there's a modicum of FUD here ;)  (*)

(*) just joking

best,
Eliot

Cheers,
 - Andreas

Reply | Threaded
Open this post in threaded view
|

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

Andreas.Raab
In reply to this post by David T. Lewis
 
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
Reply | Threaded
Open this post in threaded view
|

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

Eliot Miranda-2
 


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?  And which of those are likely to do writes to immutables?
 

Cheers,
 - Andreas

Reply | Threaded
Open this post in threaded view
|

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

Igor Stasenko
In reply to this post by Andreas.Raab

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.
Reply | Threaded
Open this post in threaded view
|

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

Igor Stasenko
In reply to this post by Eliot Miranda-2

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.
Reply | Threaded
Open this post in threaded view
|

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

Eliot Miranda-2
In reply to this post by Igor Stasenko
 


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.  This scheme also only works for methods, not for code in plugins.

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

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.

cheers,
Eliot


> Cheers,
>  - Andreas
>



--
Best regards,
Igor Stasenko AKA sig.

Reply | Threaded
Open this post in threaded view
|

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

stephane ducasse-2
In reply to this post by Andreas.Raab


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

Reply | Threaded
Open this post in threaded view
|

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

Eliot Miranda-2
In reply to this post by Igor Stasenko
 
Hi Igor,

On Wed, Jun 9, 2010 at 12:54 PM, Igor Stasenko <[hidden email]> wrote:

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?

This really isn't helpful.  I asked a specific question, not a general encouragement for FUD.  In my looking at plugins I see a few that create new objects, mutate these (obviously not an issue) and return results.  I see others that get passed in containers in which to receive results.  These latter ones need to be changed, not the former.  But I don't see that many of them.  One of the problems here is that the containers can often be written into by first asking the interpreterProxy for firstIndexableField: or firstFixedField: and then writing through the pointer which would circumvent any attempt by the interpreterProxy to enforce immutability.  But how common are these and how difficult would it be to scan for them?  There are certainly plenty of senders in my image.

cheers
Eliot


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



--
Best regards,
Igor Stasenko AKA sig.

Reply | Threaded
Open this post in threaded view
|

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

Igor Stasenko
In reply to this post by Eliot Miranda-2

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.
Reply | Threaded
Open this post in threaded view
|

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

Eliot Miranda-2
 


On Wed, Jun 9, 2010 at 1:14 PM, Igor Stasenko <[hidden email]> wrote:

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.

Consider the file-out of a method category stamp:

!FooClass methodsFor: 'category' stamp: 'initials date'!

Since a literal string is immutable and has a different class to a normal mutable string then in the original Smalltalk-80 code without changing the file-out code to take account of immutability the above printed out as

!FooClass methodsFor: 'category' copy stamp: 'initials date' copy!

So many places which used storeString et al with literals that had mutable duals (string and array literals) had to be rewritten to produce the old format.  Clumsy.

But you don't need take my word for it.  Try it and see.  Implement e.g. LiteralByteString & LiteralByteArray, modify the compiler and see how things go.

cheers,
Eliot


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



--
Best regards,
Igor Stasenko AKA sig.

12