[Vm-dev] Integration of the BlockClolsure>>value primitive

[Marcus Denker]

On 27.07.2007, at 20:24, tim Rowledge wrote:

>
> On 27-Jul-07, at 11:20 AM, Andreas Raab wrote:
>
>> Could you please post your changes for review first?
>
> And didn't we already provide some closure handling prims a couple  
> (at least) of years ago as a result of Anthony Hannan's work?  
> Wasn't the new compiler supposed to use them?

Yes, the Anthony added 189, this was added to the 3.6 vmmaker, if I  
remember correctly.
This is for Object>>#executeMethod, the speedup is substancial... but  
then, the #value
of BlockClosure remained a normal method:

value
	"Evaluate the block with no args. Fail if the block expects other  
than 0 arguments."

	^ environment executeMethod: method

vs. the one on BlockContext:

value
	"Primitive. Evaluate the block represented by the receiver. Fail if the
	block expects any arguments or if the block is already being executed.
	Optional. No Lookup. See Object documentation whatIsAPrimitive."

	<primitive: 81>
	^self valueWithArguments: #()

So for Closures, a #value requires right now a method invocation, a  
lookup
and then prim 189. Math implemented a primitive for  
BlockContext>>#value,
and the speedup is noticable (we should habe benchmarks somewhere).

We are looking into other things to speedup. e.g, BlockClosures contains
a method, on #value this method is evaluated, which means that a context
is created. BlockContexts are pre-allocated at compiletime instead.  
So for
BlockClosures beeing comparabel to BlockContexts, it is very important
to make sure that the context-cache is not flushed. The cache is  
right now
flushed far too often, e.g. on blockCopy:, which is send to  
thisContext, and
especially for the NewCompiler code on accessing the closure environment
(which is done with message sends to thisContext).

With some care (and the right bytecodes) this can be improved  
dramatically it seems.

Another thing that makes Closures slow are accesses of outer temp  
variables.
They are done with message sends right now. Having bytecodes for  
these would
make sense, too.

Just avoiding context cache flushes + the #value primitive seem to  
get some
impressive performance improvement already.... we need to do some more
extensive benchmarking, but is lools quite good already.


	Marcus
--
Marcus Denker  --  denker at iam.unibe.ch
http://www.iam.unibe.ch/~denker