squeak-vmdev

Re: [Squeak-VMdev] DING! End of Round One

[Cees de G. <cg...@cd...>]

On Fri, 2004-04-09 at 14:32, Hans-Martin Mosner wrote:
> One possible optimization would be to allow immutability only for old 
> objects - when assigning into old objects, we need additional code anyway.
>
I don't know enough about the VM to know why this makes a difference,
but one datapoint: you typically make objects immutable directly after
instantiation (e.g. reading from the datastore). Forcing them to
oldspace might have some negative performance effects.

Re: [Squeak-VMdev] Immutability [was: DING]

[Dan I. <Da...@Sq...>]

>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

Re: [Squeak-VMdev] DING! End of Round One

[Andreas R. <and...@gm...>]

> 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?

Something disturbs me about this but I'm not sure what. Maybe it's that
"bit" term - if we'd take the "immutability bit" literally it would mean
we'd have some fairly generic stuff to be dealt with here. So here's another
question: How important is it that *all* objects individually can be tagged
immutable in this way? Would it be sufficient if there would be "certain
kinds" of objects (say, classes which have a special format or similar)
which could be used that way?

Cheers,
  - Andreas

Re: [Squeak-VMdev] DING! End of Round One

[Cees de G. <cg...@cd...>]

On Fri, 2004-04-09 at 14:41, Andreas Raab wrote:
> How important is it that *all* objects individually can be tagged
> immutable in this way? Would it be sufficient if there would be "certain
> kinds" of objects (say, classes which have a special format or similar)
> which could be used that way?
> 
Ideally persistence is as transparent as possible (but, to paraphrase
Einstein, not more transparent). The persistence (transaction, .... -
there are more uses of this bit but I'll use persistence as example)
engine would ideally be able to handle all sorts of objects in the same
way: read them in, mark them immutable, handle the exception (put them
on the 'dirty' list and mark them mutable again), whether the object is
a Date or a MySpecialBusinessObject. So my first answer would be: yes,
it is important to have it everywhere.

Re: [Squeak-VMdev] DING! End of Round One

[Bert F. <be...@im...>]

Am 09.04.2004 um 18:36 schrieb Tim Rowledge:

> Bert Freudenberg <be...@im...> wrote:
>
>> Am 09.04.2004 um 01:57 schrieb Tim Rowledge:
>>>>> Flat Rectangles
>>
>> Actually, Point>>x: does not exist (can't remember when we removed 
>> it).
>> So this should be no problem at all.
> double-plus-good.
>
> This is another class I ought to have a filein for but damned if I can
> find it.  Still, not a large class IIRC. The only trick will be
> substituting it for ordinary Rectangle in the tracer but we really
> ought to be able to handle that ok.

Why wouldn't this work with a normal changeset? Does the VM know about 
Rectangles?

- Bert -

Re: [Squeak-VMdev] DING! End of Round One

[Dan I. <Da...@Sq...>]

>>This is another class I ought to have a filein for but damned if I can
>>find it.  Still, not a large class IIRC. The only trick will be
>>substituting it for ordinary Rectangle in the tracer but we really
>>ought to be able to handle that ok.

Bert asked...

>Why wouldn't this work with a normal changeset? Does the VM know about Rectangles?

Ooh.  You're right, Bert.  I forgot that this came up back when John and I were working on the original Morphic, and we wanted rectangle intersection to run faster.

It would be nice to change BitBlt correspondingly to save time and objects (we'd have to make temporary points for it after the change), but yes, I believe the whole thing can be done with a changeSet or two.

This may be a mere distraction from the more important things on the table.

	- Dan