Hi Milan,
on Sun, 25 Feb 2007 00:03:22 +0100, you wrote:
Hi Klaus, On 2007 February 24 04:07, Klaus D. Witzel wrote:
Hi Milan,
on Sat, 24 Feb 2007 09:53:50 +0100, you wrote:
<<snip>>
There are limits in the CompileMethod code such as: nTemps > 63 ifTrue: [^ self error: 'Cannot compile -- too many temporary variables']. nLits > 255 ifTrue: [^ self error: 'Cannot compile -- too many literals variables']. A naive question, does this have to do with the way classes are represented in the VM?
Since I am [in part] responsible for having the above checks in a consistent way, here's my part of the answer:
No. These limits exist because the header field in CompiledMethod has room for just these respective number of bits.
Has nothing to do with, how classes are represented in the VM, but with, how CompiledMethods are represented in the VM.
Thanks for explaining it. Considering my zero level awareness of how image interacts with the VM, and that I never looked at VM code, I should take this to the newbies list .. but anyway. I assume this limit only applies to methods compiled dynamically using ClassDescription>>compile:classified: and friends, not to methods code that I type in browser, is that correct?
No :) There is but one CompiledMethod class so the way you compile doesn't matter.
Also, I wonder how other VMs handle this, is it a performance reason that Squeak (apparently) allocates fixed space to CompileMethod header (instead of maybe making it a linked list)?
You can see the four parts of CompiledMethod better than I can describe them here, in a debugger inspect the thisContext item in the bottom right pane (second from right); in that inspector inspect the CompiledMethod. For example ('abc' at: 0) will start you the debugger, select the line which says UndefinedObject>>DoIt.
The part you refer to is the literals array which is directly indexed by bit quantities in the bytecode; there's no time for chasing a slow linked list ;-)
/Klaus
Milan
-# So I ended up "manually serializing" the ByteArray, esentially
as a
literal String such as '80 75 3 4 20 0 0 0 0 0 76 134 203' in the
small
example above. Then deserialized after the method answered.
Correct. This way you have only one literal in the CompiledMethod, instead of one literals for each value less than -1 or greater than 2 :)
/Klaus