Soon I will be able to be a fly on your shoulder and learn much faster than via emails :)
Stef >> > > Yes, but not "too much" in this sense. When creating new instances > while counting > them, the case "no problem" and "endless loop" are very close > together... a very > tiny increase, or even just a change in context-creation behavior > could trigger > the case that it creates too many contexts. > > This is one possbility: the change in creation pattern cause the > problem, nothing > to worry about. > > So let see. > > It used to be that block-context where created by sending blockCopy: > to thiscontext: > > 13 <89> pushThisContext: > 14 <75> pushConstant: 0 > 15 <C8> send: blockCopy: > 16 <A4 02> jumpTo: 20 > 18 <73> pushConstant: nil > 19 <7D> blockReturn > 20 <87> pop > 21 <78> returnSelf > > Now, the same code reads like this: > > 13 <8F 00 00 02> closureNumCopied: 0 numArgs: 0 bytes 17 to 18 > 17 <73> pushConstant: nil > 18 <7D> blockReturn > 19 <87> pop > 20 <78> returnSelf > > > and the closureNumCopied bytecode creates a BlockClosure object which > is *not* the > context. The context is later created when evaluating the Closure. > > So the time *when* an allocation of a new context may happen changed > fundamtally. > > If we now look at the code for getting allinstances: > > allInstances > "Answer a collection of all current instances of the receiver." > > | all | > all := OrderedCollection new. > self allInstancesDo: [:x | x == all ifFalse: [all add: x]]. > ^ all asArray > > (allInstancesDo: is carefully written to not use any real blocks, just > inlined ones). > > So the context for the block was created just once, before calling > #llInstancesDo: > Bytecode: > > 29 <40> pushLit: OrderedCollection > 30 <CC> send: new > 31 <68> popIntoTemp: 0 > 32 <70> self > 33 <89> pushThisContext: > 34 <76> pushConstant: 1 > 35 <C8> send: blockCopy: > 36 <A4 0B> jumpTo: 49 > .... and so on. > > Now with the Closures, it evaluates the closure in allInstancesDo:, > leading for the > closure VM to a potential allocation of a context in the execution of > allInstancesDo: > (and for each eval, it´s a loop). So we now have potentiall > allocations of new instances > of methodcontext when iterating over the existing ones. --> race > condition. > > Marcus > > > > -- > Marcus Denker - http://marcusdenker.de > PLEIAD Lab - Computer Science Department (DCC) - University of Chile > > > _______________________________________________ > Pharo-project mailing list > [email protected] > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project _______________________________________________ Pharo-project mailing list [email protected] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
