[Glass] Instances of obsolete classes after stone upgrade

Johan Brichau johan at yesplan.be
Fri Nov 19 11:59:18 PST 2021

Hi Dale,

First off: your script cleaned those obsolete instances as well. So, I think your analysis is correct ;-)

One example of a SimpleBlock instance is one defined in TimeZoneInfo>>readHeader. 
The method is an instance of GsNMethod, so that looks good. I have not analysed other methods whose blocks were still referenced. I assume they will be OK as well.

I guess I should replace our ‘recompile script’ with your script as a post upgrade step?

We’re mostly interested in discovering where in our application code we still have some complex blocks that need to be replaced before or after upgrade, so that’s why I’m looking at enumerating and clearing any lingering blocks…

Thanks again for the wonderful help. 
Appreciate it a ton!

Onwards ;-)


> I would be interested in understanding which methods are keeping the obsolete classes alive .... 
> IIRC, the older methods will be instances of GsMethod and the new methods will all be instances of GsNMethod.
> Sooo, if the methods that are hanging onto obsolete classes are instances of GsMethod then something is keeping the GsMethod instances around ... after upgrade there should be no instances of GsMethod in a Class methodDictionary ... 
> If the methods that are hanging onto obsolete classes are instances of GsNMethod, then that would be interesting ... because It implies that the method was recompiled with a reference to an Obsoloete class ... and that shouldn't happen because all of the methods should have been replaced during the upgrade process ...
> It might be possible that the session methods data structure is hanging onto instances of GsMethod. The following code should find and clean up the session method data structure
> GsPackagePolicy current
>   packages_Do: [ :gsPackage |
>     | badBoys |
>     badBoys := Dictionary new.
>     gsPackage sessionMethods
>       keysAndValuesDo: [ :behavior :ar |
>         (ar at: 1)
>           keysAndValuesDo: [ :selector :method |
>             (method isKindOf: (ObsoleteClasses at: #'GsMethod'))
>                ifTrue: [ (badBoys at: behavior ifAbsentPut: [ Set new ]) add: selector ] ] ].
>     badBoys
>       keysAndValuesDo: [ :beh :sels | sels do: [ :sel | gsPackage removeMethodAt: sel for: beh ] ] ]
> Dale
> On Fri, Nov 19, 2021 at 9:30 AM Johan Brichau via Glass <glass at lists.gemtalksystems.com <mailto:glass at lists.gemtalksystems.com>> wrote:
> Hi,
> After upgrading a GLASS/Seaside repository from to 3.4.5, I notice there are still a lot of instances of the obsolete classes SimpleBlock, ComplexVCBlock, ExecutableBlock, ComplexBlock
> We noticed these instances are references held by the methods in which they are defined. 
> Is that ‘expected’ ? Since all methods are recompiled when upgrading, should there still be instances of these obsolete block classes?
> Running the following code removes the references, but we do get a SecurityError when it tries to recompile GsPackagePolicy class>>initialize. We run it as DataCurator. Should we run it as SystemUser?
>     | obsoleteBlockClasses blockArrays sourceClasses |
>     obsoleteBlockClasses := Array withAll: (ObsoleteClasses select: [ :object | object isClass and: [ object inheritsFrom: BlockClosure ] ]).
>     blockArrays := SystemRepository listInstances: obsoleteBlockClasses.
>     sourceClasses := IdentitySet new.
>     blockArrays do: [ :blocks |
>         blocks do: [ :block |
>             block method inClass ifNotNil: [ :sourceClass |
>                 sourceClasses add: sourceClass ] ] ].
>     sourceClasses do: [ :sourceClass |
>         Transcript show: ('Recompiling class {1} ({2})' format: { sourceClass name. sourceClass asOop }).
>         sourceClass recompileAllMethods ].
> Thanks for insights!
> Johan
> _______________________________________________
> Glass mailing list
> Glass at lists.gemtalksystems.com <mailto:Glass at lists.gemtalksystems.com>
> https://lists.gemtalksystems.com/mailman/listinfo/glass <https://lists.gemtalksystems.com/mailman/listinfo/glass>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.gemtalksystems.com/mailman/archives/glass/attachments/20211119/477df4e0/attachment.htm>

More information about the Glass mailing list