[squeak-dev] The method trailer format

Colin Putney cputney at wiresong.ca
Tue Dec 15 21:53:27 UTC 2009

On 2009-12-15, at 1:22 PM, Eliot Miranda wrote:

> On Tue, Dec 15, 2009 at 12:55 PM, Michael van der Gulik <mikevdg at gmail.com> wrote:
>> It is not uncommon to have some CompiledMethod not installed in any
>> methodDictionary.
>>    CompiledMethod allInstances reject: [:e | e isInstalled]
>> Accessing associated source would become impossible in this scheme
> Where would these exist? How would they be used?
> 1.  When one redefines a method in the browser existing activations of the old method are still potentially visible in the debugger.  If you try e.g.
> Object methods for recompilation
> haltInRecompile
>    (self class whichClassIncludesSelector: thisContext messageSelector) recompile: thisContext messageSelector.
>    self halt
> the halt will occur in the old version of haltInRecompile.  The Debugger may show the method as e.g. Object>>unboundMethod.
> 2. if a package system supports overrides it is conceivable that the overridden versions of methods are kept around in the event that unloading a package will remove the overrides and need to reinstall the overridden ones. At least that's what we did in VisualWorks.
> 3.  if the system supports breakpoints in methods it is conceivable that an unbreak-pointed version of the method is squirrelled away while the break-pointed version (which may contain a hidden send of halt or breakpoint or whatever) is installed in its place.  At least that's what Terry Raymond's Professional Debug package does for VisualWorks.
> There may be other examples (John Brandt's MethodWrappers?).

SystemChangeNotifier. When a new version of a method is installed, SCN notifies all it's clients, supplying both the old method and the new method. Only the new method is actually installed in the class' method dictionary. 


More information about the Squeak-dev mailing list