Scott A Crosby wrote:

> Do you really need a header bit? What about just reserving a seperate
> range of memory for such objects, then, you just see if its in that range
> before deciding whether or not to allow the mutation.
What about changing the mutability status? This would require a gc like
operation and potentially require extending this putative area. What
happens if you need more memory for 'normal' objects - take it away from
'immutablespace'? Can objects in 'immutablespace' be modified by the
debugger? Yet another address range check to deal with... I really don't
think so. Maybe if we had a multi-exabyte address space with hardware to
provide very efficient exception raising when touching certain areas; I
have to point out that all sorts of ideas like this have been proposed
before for gc and similar activities,mostly back in the days of 8MHz
cpus when people really thought that it might be worth making Smalltalk
(or Lisp, or COBOL, or blah-blah) specific cpus. See SWORD-32, SOAR,
iAPX432 etc. Also note that nobody seems to have learnt anything from
those experiences; viz. java chips, picoJava, ARM J-code, etc. Blech.


> 
> Also, I would be careful about considering removing hashBits. Take away
> just two hashbits, and Morph becomes at least twice as slow, or even
> 1000x.
No, message _lookup_ might get badly hit, but that is only a small part
of the total speed arena. A method cache makes quite a difference, as I
think you've noticed before. Inline caches, especially polymorphic ones,
can make normal lookups so rare that simple linear method dict searches
are good enough. One might hope that progress in the dynamic translation
arena would provide an opportunity to use inline caches soon.

One could also make the point that any class with >500 methods is in
serious need of software laxatives.


> 
> May I suggest not doing any serious revamps of the image format yet. Just
> enough for the new VM.
To get BlockClosures and new method formats into usage we are going to
make a new image format anyway. And as I've noted, you can make
surprisingly big changes to object memory and gc without having to
change the object model. And if something comes up that _does_ require
major changes for a major benefit, then the pain can be weighed against
the pleasure at that time.