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: aaron@chatnbike.com t: (301) 956-2319
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 <aaron@chatnbike.com>:
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 <http://www.chatnbike.com> *e:* aaron@chatnbike.com *t:* (301) 956-2319 [image: Chat 'n Bike] [image: Chat 'n Bike]
Just as a reference. Dolphin Smalltalk supports immutability. It is really handy for marking dirty objects during persistence.
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 <bera.clement@gmail.com> 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 <aaron@chatnbike.com>:
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: aaron@chatnbike.com t: (301) 956-2319
Hi Alexandre, On Sun, May 4, 2014 at 1:09 PM, Alexandre Bergel <alexandre.bergel@me.com>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 <bera.clement@gmail.com> 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 <aaron@chatnbike.com>:
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 <http://www.chatnbike.com> *e:* aaron@chatnbike.com *t:* (301) 956-2319 [image: Chat 'n Bike] [image: Chat 'n Bike]
-- best, Eliot
Ok, thanks. It will be great to have this feature. Alexandre On May 4, 2014, at 4:58 PM, Eliot Miranda <eliot.miranda@gmail.com> wrote:
Hi Alexandre,
On Sun, May 4, 2014 at 1:09 PM, Alexandre Bergel <alexandre.bergel@me.com> 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 <bera.clement@gmail.com> 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 <aaron@chatnbike.com>: 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: aaron@chatnbike.com t: (301) 956-2319
-- best, Eliot
-- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
Hi Aaron, On Sun, May 4, 2014 at 8:40 AM, Aaron Rosenzweig <aaron@chatnbike.com>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 <http://www.chatnbike.com> *e:* aaron@chatnbike.com *t:* (301) 956-2319 [image: Chat 'n Bike] [image: Chat 'n Bike]
-- best, Eliot
participants (6)
-
Aaron Rosenzweig -
Alexandre Bergel -
Clément Bera -
Eliot Miranda -
Esteban A. Maringolo -
Sebastian Sastre