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 <[email protected]> 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 <[email protected]>: >> 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: [email protected] t: (301) 956-2319 >> >> >
