[Newcompiler] Finding enough bytecodes for closures.

[Marcus Denker]

On 01.05.2007, at 19:52, Klaus D. Witzel wrote:

>>
>> But there are many cases of BlockClosures that reference no external
>> variables... e.g. along the example given by bryce:
>>
>> 	someDict at: #test ifAbsentPut: ['hello']
>>
>> here the block has no variables at all, thus is does not need to have
>> an Environment.
>
> Sure (now repeated, how many times? :) There are cases where no  
> Env's are needed. But you cannot design+build the new compiler for  
> just the cases where no Env is needed?
>
No, of course not. But there might be designs without explicit  
environments as objects... at least one thing that could be done is  
to only put *shared* variables in an environment and
have the others in the methodcontexts.

>>>
>>> Sure "only if needed" but otherwise nobody would need a new
>>> compiler which handles full BlockClosures.
>>>
>>
>> But they are not needed in *all* cases. ['I am a block'] does not
>> need an environment for storing variables.
>
> *absolutely* *no* *problem* *and* *never* *seen* *as* *a* *problem*  
> *here* (apologies for the emphasis) but that cannot be taken as the  
> general case

No. But it should pay to optimize this, because blocks with no  
external references are quite common.

> (and just the latter is my point, nothing more). Instead, efficient  
> code needs to be generated for precisely the opposite case(s). Is  
> it possible we agree on this one?

We need fast code for the general case, yes.

>>>> Removing
>>>> the closures is just creating extra kinds of block similar to the
>>>> different kinds of context that Eliot added in VisualWorks
>>>> 5i. Creating extra context types is probably not needed to equal
>>>> or better
>>>> the current code in most cases.
>>>
>>> Yes (extra context types probably not needed to equal or better),
>>> me too thinks that's not really needed.
>>
>> It would be nice to make it simple and uniform.... the current
>> BlockContext scheme preceeds the contex-recycling
>> scheme...
>
> There's one particular reason why #pushActiveContextBytecode has to  
> cancel (as noted by Bryce in the other thread) the recycling  
> possibility of contexts: any piece of code could have stored the  
> context (MethodContext and BlockContext alike) behind the VM's  
> back, say for example into a slot of a longer living object (like  
> in an iVar). From then on recycling is impossible.
>
yes. As soon as you access thisContext.

> Can we agree that this situation (cause+effect) cannot change,  
> regardless of using MethodContext, BlockContext, BlockClosures or  
> any replacement for the latter?
>

But what we can change is that we push thisContext to access the  
environment... it did something like:

	pushThisContext
	pushConstant: 5
	send: privGetInstVar:

So the thisContext is never referenced (and stored in a ivar, moved  
around..) but only put on the stack to
get the 5th instVar of it. If we do that in the bytecode like this:

!Interpreter methodsFor: 'stack bytecodes' stamp: 'ms 4/24/2007 15:08'!
pushClosureEnvironment

	self fetchNextBytecode.
	self internalPush: (self fetchPointer: 4 ofObject: activeContext).
! !

!Interpreter methodsFor: 'stack bytecodes' stamp: 'ms 4/28/2007 11:12'!
storeClosureEnvironment
	"Byte code for the closure environment"
	self fetchNextBytecode.

	self storePointer: 4 ofObject: activeContext  withValue: self  
internalStackTop! !


We never need to push the thisContext at all...

	Marcus


-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 3947 bytes
Desc: not available
Url : http://lists.squeakfoundation.org/pipermail/newcompiler/attachments/20070501/bddf8204/smime-0001.bin