|
From: Dan I. <Da...@Sq...> - 2004-04-09 15:40:11
|
>Cees de Groot wrote: >>Well, as far as you can classify my thinking on this subject as being serious (me being a total nitwit in this area), pseudocode-wise it would be: >> >>Object>>instVarAt: anInteger put: anObject >> self isImmutable ifTrue: [ >> AttemptToWriteImmutableObjectException new receiver: self; index: anInteger; value: anObject; >> raise]. >> <original code> >> >> >> Hi, Hans-Martin - >The instVarAt:put: primitive (and the at:put: primitive for indexed access) can just check the immutability bit - the additional overhead should be small. >The inst var assignments in methods are more complicated. >One possible optimization would be to allow immutability only for old objects - when assigning into old objects, we need additional code anyway. >The beImmutable primitive would make sure that the receiver is either old already, or it would move the oldspace boundary to point after the objects. >Does that sound sane? I worry a lot about any interference with the GC's own movements of objects. I can say more about this, but at another time. The thought I had is to use the multiple interpreters hack here -- one dispatch table if the receiver is immutable, another if it's not. Almost all the tables are the same except for storeInstVar and friends. So the net overhead is zero except for the one test at send time. I haven't thought what the analog is for a JIT. - Dan |