<div dir="ltr"><div>Hi,</div><div>Some CompiledMethod might be replaced in their respective MethodDictionary (recompiled), but persist in the system when they have some block referenced.</div><div><br></div><div>We can track them down with this snippet:</div><div><br></div><div>     (CompiledMethod allInstances reject: #isInstalled) inspect.</div><div><br></div><div>Most of the time, it's innocuous, but if the method were recompiled due to a change of class layout and if the block access inst. var. slots that since moved, all sort of undefined behavior can happen, including a VM crash.</div><div><br></div><div>I thought I could track such case down with this snippet:</div><br><div>    (CompiledBlock allInstances reject: [:e | e isClean or: [each home method isInstalled]]) inspect.</div><div><br></div><div>or:</div><div><br></div><div>    (BlockContext allInstances reject: [:e | e closure isClean or: [each home method isInstalled]]) inspect.</div><div><br></div><div>But both BlockContext and CompiledBlock allInstances isEmpty. Ah yes, CompiledBlock is future for Sista, and now we only get Context in Spur...<br></div><div><br>    (Context allSubInstances reject: [:e | e methods isInstalled]) inspect.</div><div><br></div><div>gives a longer list than the first snippet, because the out-of-date method might be used in many different context...</div><div><br></div><div>However, I can't find those having dangerous (not clean) blocks:</div><div><br></div><div>    (Context allSubInstances reject: [:e | e closure isNil]) inspect.<br>    (Context allSubInstances reject: [:e | e closure isNil or: [e closure isClean]]) inspect.<br></div><div>    (Context allSubInstances reject: [:e | e closure isNil or: [e closure isClean or: [e method isInstalled]]]) inspect.</div><div><br></div><div>The first two lists are not empty, but the last one is empty. So that's still  not the right invocation: there is no active Context for those closure, so here is a better snippet:</div><div><br></div><div>    (BlockClosure allSubInstances reject: [:e | e outerContext method isInstalled or: [e isClean]]) inspect.</div><div><br></div><div>In a VMMaker image built from latest squeak distribution, the out-of-date CompiledMethods given by the first snippet is below:</div><div><div><br></div><div>(WorldMenuProvider>>#preferencesBrowser "a CompiledMethod(3800333)") .</div>(WorldMenuProvider>>#nextWindow "a CompiledMethod(1345923)") .<br>(WorldMenuProvider>>#closeTopWindow "a CompiledMethod(1052691)") .<br>(WorldMenuProvider>>#helpOnServices "a CompiledMethod(1013869)") .<br>(WorldMenuProvider>>#rebuildRegistry "a CompiledMethod(2839737)") .<br>(WorldMenuProvider>>#servicesBrowser "a CompiledMethod(485047)") .<br>(WorldMenuProvider>>#createNewService "a CompiledMethod(2658559)") .<br>(WorldState>>#stepListSortBlock "a CompiledMethod(491105)") .<br>(ServiceAction class>>#id:text:button:description:action: "a CompiledMethod(3812069)") .<br>(ServiceAction class>>#text:button:description:action: "a CompiledMethod(1460587)") .<br>(ServiceCategory class>>#text:button:description: "a CompiledMethod(3025003)") .<br>(ServiceShortcuts class>>#insertPrefShortcut: "a CompiledMethod(2077141)") .<br>(WeakRegistry>>#installFinalizer "a CompiledMethod(1322897)") .<br>(PluggableDictionary class>>#integerDictionary "a CompiledMethod(353359)") .<br>(Slider>>#computeSlider "a CompiledMethod(682213)") .<br>(MorphicAlarmQueue>>#migrate "a CompiledMethod(1994485)") .<br>(SqueakReleaseNotes class>>#asHelpTopic "a CompiledMethod(79489)") .<br><div>(SqueakTheme class>>#addToolColors: "a CompiledMethod(1225541)") .</div><div><br></div><div>+ a bunch of DoIt's for which I can't find the pointers (referenced by nothing, can it be a memory leak from VM?).</div><div><br></div><div>By using 'chase pointers' menu, or the second snippet to catch Context, most come from ServiceRegistry.</div><div>There are also special sortBlock for Heap (stepListSortBlock from WorldState>>initialize and also WorldState alarms) or hashBlock (integerDictionary from Unicode ToUpper).</div><div>The HostWindowProxy registry has the obsolete installFinalizer.</div><div><br></div><div>And the unclean closure given by latest snippet are very few (copy omitted):</div><div><br>[closure] in WorldMenuProvider>>helpOnServices<br>[closure] in ServiceShortcuts class>>insertPrefShortcut:</div><div>[closure] in WeakRegistry>>installFinalizer<br>[closure] in MorphicAlarmQueue>>migrate</div><div><br></div><div>Most are not clean because they close over self or a method argument.</div><div>The only potentially problematic is the one closing over an inst. var. (more over for writing!) WeakRegistry>>installFinalizer.</div><div>It would be safer to transform this closure to just send a message rather than messing directly with the ivar...</div><div><br></div><div>It's not a problem right now until we change WeakRegistry layout, but I wanted to share these findings, since that's the kind of tricky things we must care of when releasing a new version.</div><div><br></div><div><br></div><div><br></div></div></div>