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

[Mathieu Suen]

Hi

Did someone have time to look at my changes?
Thanks

	Mth



On Aug 5, 2007, at 8:35 PM, Marcus Denker wrote:

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