Ok this is in the image I did not remember (getting old) :) but the vm pay
attention
not to crash totally when you put nil in a methodDict.
Now what I know is that a while back when we activate
Smalltalk at: #MDFaultDict put: Dictionary new.
We kind of either crashed or got all the classes of the system in.
I have the impression that this is just a hack and I would remove it from the
system
because we can do with MW or reflectivity (even if we probably cannot trace the
tracing code).
Also the granularity is really the class so as soon as one method is invoked
you get all the class back.
So with mathieu we simply something could not understand why all the classes
would be touched
may be browser was scanning all the image. No idea. but at the end it was not
useful.
Stef
On Dec 23, 2009, at 4:51 PM, Adrian Kuhn wrote:
> Mariano Martinez Peck <marianop...@...> writes:
>
>> So, it seems to HACK (it forces a fault) this MD fault recover to discover
>> inactive classes and other things. Ok, forget that hack for a moment.
>>
>> What questions is, what are these faults? Why a method dictionary can be in
>> nil ? How is this produced ? And how is it fixed?
>>
>> I saw for example this:
>>
>> Behaviour>>methodDict
>> methodDict == nil ifTrue: [self recoverFromMDFaultWithTrace].
>> ^ methodDict
>>
>> But again...how can that be nil ???
>
> I guess your missing link is
>
> ProtoObject >> #cannotInterpret:
>
> which is executed by the VM whenever you try to send a message to an object
> whose class does not have a method dictionary. Further methods that you should
> look at are
>
> ClassDescription >> #induceMDFault
> ClassDescription >> #recoverFromMDFault
> ClassDescription >> #recoverFromMDFaultWithTrace
>
> and their senders. Except for the call to #cannotInterpret by the VM, all the
> rest is done in the image (stef got that wrong) and you can go and read the
> code. All in all, it is a highly sophisticated (read *ugly*) hack and I'd say
> an evil use of superpowers.
>
> --AA
>
>
>
>
>
>
> _______________________________________________
> 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
