Adrian: Thanks, indeed cannotInterpret: was what I was looking for :) On Wed, Dec 23, 2009 at 5:19 PM, Stéphane Ducasse <[email protected] > wrote:
> 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. > > ok > 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). > What's MW ? Now...the question is, suppose I remove all the methods like discoverUnusedCLasses, activeClasses, and so on, can I remove also the methods induceMDFault, recoverFromMDFault, etc ??? Or there are other users? As I understood, there aren't. In addition, I don't see the relation between cannotInterpret: and those methods, because cannotInerpret: does not call this methods to recover. > Also the granularity is really the class so as soon as one method is > invoked you get all the class back. > Yes, I noticed that too. Is very probable that messages very general that are used a lot will bring the class again. > 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. > That's the idea of the tracer. WIth this tracer you *should* be able to see the messages chain that makes you bring the class (why it was used). But I don't know if this stuff is working, as you said. > > 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 >
_______________________________________________ Pharo-project mailing list [email protected] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
