[vm] Large Frame size

Rob Withers schrieb:
> I have a need for a larger frame size.  I am defining internal temps
> for some changes I am making with macro transformations, and I ran
> into the limit of the frame size when compiling some method in the
> image.   So what would be a good frame size for the large frame?  
> Could someone guide me as to what I would need to change in the vm to
> support this?  Will I need to use the SystemTracer to get an image
> prepared for using them and avoiding problems with the old large frame
> size going away?
>  
An easier solution might be to modify the compiler to stuff some temps
into an Array and generate code to access that Array where you would
normally generate temp var accesses. That way, you don't have to change
the VM, and the cost would only be paid for the very few methods
exceeding Squeak's large frame size.

Cheers,
Hans-Martin

----- Original Message -----
From: "Hans-Martin Mosner" <[hidden email]>
To: "The general-purpose Squeak developers list"
<[hidden email]>
Sent: Tuesday, October 23, 2007 1:50 PM
Subject: Re: [vm] Large Frame size


That's a very interesting idea.  When/Where could I initialize the array?

I dug deeper and found some interesting things.  It is not just the internal
temps that I am defining that is creating the need for more frame size.  I
am also increasing the depth of the stack needed, as code that once was
macroed, is now a first class message send, and so are pushing args onto the
stack.   This seems to get worse with nested calls for some reason.

For example, in the GeniePlugin, the method
#primSameClassAbsoluteStrokeDistanceMyPoints:otherPoints:myVectors:otherVectors:mySquaredLengths:otherSquaredLengths:myAngles:otherAngles:maxSizeAndReferenceFlag:rowBase:rowInsertRemove:rowInsertRemoveCount:
normally generates nTemps: 50  and stackDepth: 6, exactly the large frame
size.  With the code changing the macro transforms on, it generates: nTemps:
50  stackDepth: 15.  Finally with the macro temps turned on it generates
nTemps: 63  stackDepth: 15.  This seems to be due to nested #to:do: calls
with #ifTrue:ifFalse:, both of which I am transforming.

So, even without using macro temps, I am still looking at a frame size of
65, exceeding the large frame size of 56.  The max is 78.  I think I'll work
on defining a frame size of 80, as a nice round number.

Will I need to use the SystemTracer to make this change, or will it create
the right size contexts when I run an image file?

Cheers,
Rob

----- Original Message -----
From: "Rob Withers" <[hidden email]>

> I think I'll work on defining a frame size of 80, as a nice round number.

I just read the following comment in ObjectMemory
class>>#initializeWithBytesToWord:

 "Large contexts have 56 indexable fileds.  Max with single header word."

Could someone explain what this is all about?  What is it about a single
header word that limits it?

thanks,
Rob

Rob Withers schrieb: The single header word includes a size field which encodes for a maximum
of 63 oop slots, of which one is the header word itself, 6 are instance
variables, leaving 56 indexable slots.
Larger contexts would need a second and third header field to hold the
object size. The comment to which you're referring indicates that in 64
bit images, the context objects would need 3 header words, so it seems
the VM should be able to handle it (however, I don't know whether it
handles the mixture of 1 word headers for small contexts and 3 words for
large contexts.)

Cheers,
Hans-Martin

----- Original Message -----
From: "Hans-Martin Mosner" <[hidden email]>
To: "The general-purpose Squeak developers list"
<[hidden email]>
Sent: Tuesday, October 23, 2007 10:47 PM
Subject: Re: [vm] Large Frame size


What are the 6 instance variables for?  Ahh, I see: sender, pc, sp, method,
(unused), receiver.

> Larger contexts would need a second and third header field to hold the
> object size. The comment to which you're referring indicates that in 64
> bit images, the context objects would need 3 header words, so it seems
> the VM should be able to handle it (however, I don't know whether it
> handles the mixture of 1 word headers for small contexts and 3 words for
> large contexts.)

Ok, so after reading through the appropriate ObjectMemory code, it looks as
if  #instantiateContext:sizeInBytes: is already setup to handle a situation
where the size exceeds the max size for a 2 word header, and uses a 3 word
header if that's the case.  So I just initialized LargeContextSize to be 87
words and regenerated the vm.  I changed the corresponding size in
CompiledMethod.  I recompiledAll.  Everything seems to work.

Thanks, Hans!
Rob