[Newcompiler] Finding enough bytecodes for closures.

[bryce at kampjes.demon.co.uk]

Right,
Thanks why I'm reasonably confident that environment creation is
not a problem. We'll lose a little by creating an extra object
but potentually save a lot by being able to recycle more contexts.

Bryce

Marcus Denker writes:
 > 
 > 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
 > 
 >