Smalltalk › Pharo › Pharo Smalltalk Developers

Immutability in the VM - is it hard?

_‹ Previous Topic Next Topic _›

Classic

List

Threaded

8 messages Options

Aaron Rosenzweig

Immutability in the VM - is it hard?

Hello,

Why is the concept of “immutability” special to VisualWorks? Is it something hard to add to other Smalltalk dialects such as Pharo or are there other reasons for not having it?

When I read the docs for the GOODS database client it says the following:

“The GOODS client uses this immutability support for change detection.”

It goes on to say that this is only for VisualWorks. For Pharo it says that it is generally slow to commit changes because the client to the OODB has to spent extra time detecting change detection. I guess for VisualWorks it is basically “free” to detect a change in an object.

Thank you,

Aaron Rosenzweig / Chat 'n Bike e: [hidden email] t: (301) 956-2319

Clément Béra

Re: Immutability in the VM - is it hard?

Hello,

Immutability needs to be implemented in the VM. It is quite some work on the current memory manager. Few people have enough skills to do this kind of changes nicely and efficiently, and none of them had enough time to do it. However, things are now moving quicker and quicker and some work and immutability has started.

Right now part of the VM work is focusing the new memory manager Spur that will be released for Pharo 4. This new memory manager will feature immutability (1 bit in the object header is now reserved for this purpose). However, although immutability is required by some projects and people, it is quite far away on the To Do list right now (firstly, the new memory manager needs to work efficiently, be stable, be in production, ...). Therefore, you may have to wait for Pharo 5 (2 years from now) to have immutability in production.

Best,

Clement

2014-05-04 8:40 GMT-07:00 Aaron Rosenzweig <[hidden email]>:

Hello,

Why is the concept of “immutability” special to VisualWorks? Is it something hard to add to other Smalltalk dialects such as Pharo or are there other reasons for not having it?

When I read the docs for the GOODS database client it says the following:

“The GOODS client uses this immutability support for change detection.”

It goes on to say that this is only for VisualWorks. For Pharo it says that it is generally slow to commit changes because the client to the OODB has to spent extra time detecting change detection. I guess for VisualWorks it is basically “free” to detect a change in an object.

Thank you,
Aaron Rosenzweig / Chat 'n Bike
e: [hidden email] t: <a href="tel:%28301%29%20956-2319" value="+13019562319" target="_blank">(301) 956-2319

Eliot Miranda-2

Re: Immutability in the VM - is it hard?

In reply to this post by Aaron Rosenzweig

Hi Aaron,

On Sun, May 4, 2014 at 8:40 AM, Aaron Rosenzweig <[hidden email]> wrote:

Hello,

Why is the concept of “immutability” special to VisualWorks? Is it something hard to add to other Smalltalk dialects such as Pharo or are there other reasons for not having it?

First, the concept isn't special to VisualWorks. The VisualAge VM had it before VW (AFAIA VA had it first) and I implemented it for VisualWorks in the early 2000's to allow the GemStone implementation on VisualWorks to be as simple as it is on VisualAge.

Second, I implemented immutability for the Newspeak Interpreter VM, a modified Squeak interpreter VM, in 2007 and you'll find that code in the VMMaker.oscog package in the NewspeakInterpreter class.

So no, it's not hard to add. It's simply hard to find the time to port the code from the NewspeakInterpreter VM to the Cog VM. Volunteers are encouraged to have a go and I'm very happy to give advice. Right now my priority is getting the 32-bit Spur port deployed (and having implemented a functional compaction algorithm this last week I can now do so).

When I read the docs for the GOODS database client it says the following:

“The GOODS client uses this immutability support for change detection.”

It goes on to say that this is only for VisualWorks. For Pharo it says that it is generally slow to commit changes because the client to the OODB has to spent extra time detecting change detection. I guess for VisualWorks it is basically “free” to detect a change in an object.

It's pretty cheap, but not quite free. It's quite simple. When immutability is implemented, the system uses a bit in the object header as a per-object immutability flag, and checks the bit before every assignment. An attempt to assign an inst var in an immutable object causes a send-back of attemptToAssign: theValue withIndex: instVarIndex to the immutable object being assigned. An attempt to assign an immutable object in a primitive causes that primitive to fail with a PrimErrNoModification primitive failure code. IIRC the VW VM slowed by about 6% when immutability was implemented. I hope that on modern machines the slowdown would be even less, but the extra read of the object header during inst var assignment is a significant cost. The cost for primitives is much less because bounds checking implies a read of the object header to determine an object's size anyway.

HTH

and pardon me for asking that in future you cc vm-dev for VM-related discussions. Thanks.

Thank you,
Aaron Rosenzweig / Chat 'n Bike
e: [hidden email] t: <a href="tel:%28301%29%20956-2319" value="+13019562319" target="_blank">(301) 956-2319

best,

Eliot

Esteban A. Maringolo

Re: Immutability in the VM - is it hard?

In reply to this post by Clément Béra

Just as a reference. Dolphin Smalltalk supports immutability. It is really handy for marking dirty objects during persistence.

abergel

Re: Immutability in the VM - is it hard?

In reply to this post by Clément Béra

Why is immutability related to the memory management? Are you referring to the change in the header, therefore the garbage collector has to be aware of the extra bit?

Cheers,

Alexandre

Le 04-05-2014 à 12:05, Clément Bera <[hidden email]> a écrit :

Hello,

Immutability needs to be implemented in the VM. It is quite some work on the current memory manager. Few people have enough skills to do this kind of changes nicely and efficiently, and none of them had enough time to do it. However, things are now moving quicker and quicker and some work and immutability has started.

Right now part of the VM work is focusing the new memory manager Spur that will be released for Pharo 4. This new memory manager will feature immutability (1 bit in the object header is now reserved for this purpose). However, although immutability is required by some projects and people, it is quite far away on the To Do list right now (firstly, the new memory manager needs to work efficiently, be stable, be in production, ...). Therefore, you may have to wait for Pharo 5 (2 years from now) to have immutability in production.

Best,
Clement

2014-05-04 8:40 GMT-07:00 Aaron Rosenzweig <[hidden email]>:

Hello,

Why is the concept of “immutability” special to VisualWorks? Is it something hard to add to other Smalltalk dialects such as Pharo or are there other reasons for not having it?

When I read the docs for the GOODS database client it says the following:

“The GOODS client uses this immutability support for change detection.”

It goes on to say that this is only for VisualWorks. For Pharo it says that it is generally slow to commit changes because the client to the OODB has to spent extra time detecting change detection. I guess for VisualWorks it is basically “free” to detect a change in an object.

Thank you,
Aaron Rosenzweig / Chat 'n Bike
e: [hidden email] t: <a href="tel:%28301%29%20956-2319" value="+13019562319" target="_blank">(301) 956-2319

sebastianconcept@gmail.co

Re: Immutability in the VM - is it hard?

In reply to this post by Esteban A. Maringolo

On May 4, 2014, at 2:17 PM, Esteban A. Maringolo <[hidden email]> wrote:

Just as a reference. Dolphin Smalltalk supports immutability. It is really handy for marking dirty objects during persistence.

I remember using that feature there once or twice

Eliot Miranda-2

Re: Immutability in the VM - is it hard?

In reply to this post by abergel

Hi Alexandre,

On Sun, May 4, 2014 at 1:09 PM, Alexandre Bergel <[hidden email]> wrote:

Why is immutability related to the memory management?

It isn't.

Are you referring to the change in the header, therefore the garbage collector has to be aware of the extra bit?

The object representation needs to make room for the bit in the header, but the GC ignores it completely. However, the memory manager (of which the GC is a component) implements the core of e.g. the become primitive and that primitive can reasonably be expected to fail an attempt to become an immutable object.

Cheers,

Alexandre

Le 04-05-2014 à 12:05, Clément Bera <[hidden email]> a écrit :

Hello,

Immutability needs to be implemented in the VM. It is quite some work on the current memory manager. Few people have enough skills to do this kind of changes nicely and efficiently, and none of them had enough time to do it. However, things are now moving quicker and quicker and some work and immutability has started.

Right now part of the VM work is focusing the new memory manager Spur that will be released for Pharo 4. This new memory manager will feature immutability (1 bit in the object header is now reserved for this purpose). However, although immutability is required by some projects and people, it is quite far away on the To Do list right now (firstly, the new memory manager needs to work efficiently, be stable, be in production, ...). Therefore, you may have to wait for Pharo 5 (2 years from now) to have immutability in production.

Best,
Clement

2014-05-04 8:40 GMT-07:00 Aaron Rosenzweig <[hidden email]>:

Hello,

Why is the concept of “immutability” special to VisualWorks? Is it something hard to add to other Smalltalk dialects such as Pharo or are there other reasons for not having it?

When I read the docs for the GOODS database client it says the following:

“The GOODS client uses this immutability support for change detection.”

It goes on to say that this is only for VisualWorks. For Pharo it says that it is generally slow to commit changes because the client to the OODB has to spent extra time detecting change detection. I guess for VisualWorks it is basically “free” to detect a change in an object.

Thank you,
Aaron Rosenzweig / Chat 'n Bike
e: [hidden email] t: <a href="tel:%28301%29%20956-2319" value="+13019562319" target="_blank">(301) 956-2319

--
best,

Eliot

abergel

Re: Immutability in the VM - is it hard?

Ok, thanks.
It will be great to have this feature.

Alexandre

On May 4, 2014, at 4:58 PM, Eliot Miranda <[hidden email]> wrote:

> Hi Alexandre,
>
>
> On Sun, May 4, 2014 at 1:09 PM, Alexandre Bergel <[hidden email]> wrote:
> Why is immutability related to the memory management?
>
> It isn't.
>
> Are you referring to the change in the header, therefore the garbage collector has to be aware of the extra bit?
>
> The object representation needs to make room for the bit in the header, but the GC ignores it completely. However, the memory manager (of which the GC is a component) implements the core of e.g. the become primitive and that primitive can reasonably be expected to fail an attempt to become an immutable object.
>
>
> Cheers,
> Alexandre
>
> Le 04-05-2014 à 12:05, Clément Bera <[hidden email]> a écrit :
>
>> Hello,
>>
>> Immutability needs to be implemented in the VM. It is quite some work on the current memory manager. Few people have enough skills to do this kind of changes nicely and efficiently, and none of them had enough time to do it. However, things are now moving quicker and quicker and some work and immutability has started.
>>
>> Right now part of the VM work is focusing the new memory manager Spur that will be released for Pharo 4. This new memory manager will feature immutability (1 bit in the object header is now reserved for this purpose). However, although immutability is required by some projects and people, it is quite far away on the To Do list right now (firstly, the new memory manager needs to work efficiently, be stable, be in production, ...). Therefore, you may have to wait for Pharo 5 (2 years from now) to have immutability in production.
>>
>> Best,
>> Clement
>>
>>
>> 2014-05-04 8:40 GMT-07:00 Aaron Rosenzweig <[hidden email]>:
>> Hello,
>>
>> Why is the concept of “immutability” special to VisualWorks? Is it something hard to add to other Smalltalk dialects such as Pharo or are there other reasons for not having it?
>>
>> When I read the docs for the GOODS database client it says the following:
>>
>> “The GOODS client uses this immutability support for change detection.”
>>
>> It goes on to say that this is only for VisualWorks. For Pharo it says that it is generally slow to commit changes because the client to the OODB has to spent extra time detecting change detection. I guess for VisualWorks it is basically “free” to detect a change in an object.
>>
>> Thank you,
>> AARON ROSENZWEIG / Chat 'n Bike
>> e: [hidden email] t: (301) 956-2319
>>
>>
>>
>
>
>
> --
> best,
> Eliot

--
_,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
Alexandre Bergel http://www.bergel.eu
^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.