2009/8/5 Marcus Denker <[email protected]>:
>
> On 05.08.2009, at 12:30, Igor Stasenko wrote:
>
>> 2009/8/5 Marcus Denker <[email protected]>:
>>>
>>> On 05.08.2009, at 12:00, Stéphane Ducasse wrote:
>>>
>>>> I did that in pharo 211 and it worked.
>>>>
>>> Yes, that was before closures.
>>>
>>>> MethodContext allInstances size 2309
>>>>
>>>
>>> with the blockClosures, creation of method contexts happes far more
>>> frequently than it used to.
>>> (as both closures and methods use the same context objects)
>>>
>>> It of course could be a sign that it happens actually too much.
>>>
>> Hmm, if that so, then we would expect to see an interpreter speed
>> degradation. But its not. :)
>
> Yes, see the other mail. The reason is that the allocation of contexts
> in case of blocks happens now at #value, whereas it used to be just done
> at the definiton point (#blockCopy).
>
> So nothing to worry about.
>
Could it be rewritten to something like that:
( for all classes except UndefinedObject)
allInstances
| all inst next |
all := OrderedCollection new.
inst := self someInstance.
inst ifNil: [ ^ #() ].
[inst == 0]
whileFalse:
[
next := inst nextObject.
next class == self ifTrue: [ all add: next ].
next == all ifTrue: [ ^ all ].
inst := next].
^ all
here i added the stop rule ' next == all ifTrue: [ ^ all ].' , which
should return from the loop once heap reached the last allocated
object.
The caller of #allInstances expects to see all instances of class
existed before invocation of this method, and not interested in those
ones, which was created as a side effect of running it. Right?
>> I think it is correct behavior, that you can't get #allInstances of
>> class when you creating them in a loop which serves to collect them
>> all.
>> The solution would be to collect #allInstances primitively (by a
>> single primitive call), then there is no chance that anything happen
>> with object memory during memory scan by primitive.
>
>
> Yes, and the real solution of course is to change the VM to allocate
> less
> contexts and use the C-stack instead...
>
hmm, doesn't that breaks the smalltalk introspection capabilities,
since then you can't see all the
context objects which is used by interpreter for running your code?
I want to point, that the way how VM allocating contexts is
implementation details , and if it done correctly
then you're still should be able to access all context objects.
> Marcus
>
>>>
>>> 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
>>>
>>
>>
>>
>> --
>> Best regards,
>> Igor Stasenko AKA sig.
>>
>> _______________________________________________
>> 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
>
--
Best regards,
Igor Stasenko AKA sig.
_______________________________________________
Pharo-project mailing list
[email protected]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
