Hi folks,
What's the state of the art in shrinking these days?
I'm starting a new web project with Squeak, and I want to create a smallish base image that I can use to build up images for development and deployment. It doesn't have to be absolutely minimal, just unloading unnecessary code and cleaning up the registries, clearing caches etc would fine.
I tried "Smalltalk shrinkAndCleanDesktop", but it complains about obsolete behaviours still being present, so I guess there's some bit rot there.
Suggestions?
Colin
On 6 January 2014 20:56, Colin Putney colin@wiresong.com wrote:
Hi folks,
What's the state of the art in shrinking these days?
I'm starting a new web project with Squeak, and I want to create a smallish base image that I can use to build up images for development and deployment. It doesn't have to be absolutely minimal, just unloading unnecessary code and cleaning up the registries, clearing caches etc would fine.
I tried "Smalltalk shrinkAndCleanDesktop", but it complains about obsolete behaviours still being present, so I guess there's some bit rot there.
Suggestions?
Tobias Pape's the person to most recently attempt to shrink the image: I'd start by seeing what he stubbed his toes against. Tobias found that MC packages don't unload in the correct way: they do call a class's #unload (but only because MCClassDefinitions call their class's #removeFromSystem), but only do so after the class's methods have all been unloaded. That means that often the machinery needed to unload the class has already been unloaded. It looks... a bit messy to get things to work properly, possibly involving faking SystemChangeNotifier notifications of method removals.
frank
Colin
On 06.01.2014, at 21:56, Colin Putney colin@wiresong.com wrote:
Hi folks,
What's the state of the art in shrinking these days?
I'm starting a new web project with Squeak, and I want to create a smallish base image that I can use to build up images for development and deployment. It doesn't have to be absolutely minimal, just unloading unnecessary code and cleaning up the registries, clearing caches etc would fine.
I tried "Smalltalk shrinkAndCleanDesktop", but it complains about obsolete behaviours still being present, so I guess there's some bit rot there.
Before trying to shrink, check that there are _not_ the 8 Obsoletes I talked about in 94EA41C1-42EF-462E-8883-A8999AA7CB03@gmx.de (http://forum.world.st/Obsoletes-tp4732904p4732931.html)
Best -Tobias
On Mon, Jan 6, 2014 at 4:40 PM, Tobias Pape Das.Linux@gmx.de wrote:
Before trying to shrink, check that there are _not_ the 8 Obsoletes I talked about in 94EA41C1-42EF-462E-8883-A8999AA7CB03@gmx.de ( http://forum.world.st/Obsoletes-tp4732904p4732931.html)
Aha!
In the latest Trunk, there's only 6 obsolete classes, as the recent Environment changes fixed the two of them. The following script, adapted from your post above, cleans them up nicely:
" Fix obsolete ColorTheme" ColorTheme current class isObsolete ifTrue: [ ColorTheme current: nil. Smalltalk garbageCollect. ColorTheme current].
" Fix obsolete uncle classes (cls->meta->super)" (Smalltalk allClasses select: [:cls | cls theMetaClass superclass isObsolete] ) copy do: [:withObsoleteUncle | | cls2 | cls2 := withObsoleteUncle addInstVarName: 'veryUnlikelyToExisitAnywhereInTheSystemAsVariableName'. Smalltalk garbageCollect. cls2 removeInstVarName: 'veryUnlikelyToExisitAnywhereInTheSystemAsVariableName'.]. Smalltalk garbageCollect. Smalltalk fixObsoleteReferences.
Running "Smalltalk shrink" then complains about two obsolete behaviours, and I this is a bug with Installer. If I just close the debugger and inspector, collect garbage and then run "SystemNavigation default obsoleteBehaviors" I get an empty array.
So it looks like the shrink works. It doesn't do much, though. My image goes from 20.9MB, down to 20.3MB.
Colin
On Mon, Jan 6, 2014 at 4:35 PM, Colin Putney colin@wiresong.com wrote:
On Mon, Jan 6, 2014 at 4:40 PM, Tobias Pape Das.Linux@gmx.de wrote:
Before trying to shrink, check that there are _not_ the 8 Obsoletes I talked about in 94EA41C1-42EF-462E-8883-A8999AA7CB03@gmx.de ( http://forum.world.st/Obsoletes-tp4732904p4732931.html)
Aha!
In the latest Trunk, there's only 6 obsolete classes, as the recent Environment changes fixed the two of them. The following script, adapted from your post above, cleans them up nicely:
" Fix obsolete ColorTheme" ColorTheme current class isObsolete ifTrue: [ ColorTheme current: nil. Smalltalk garbageCollect. ColorTheme current].
" Fix obsolete uncle classes (cls->meta->super)" (Smalltalk allClasses select: [:cls | cls theMetaClass superclass isObsolete] ) copy do: [:withObsoleteUncle | | cls2 | cls2 := withObsoleteUncle addInstVarName: 'veryUnlikelyToExisitAnywhereInTheSystemAsVariableName'. Smalltalk garbageCollect. cls2 removeInstVarName: 'veryUnlikelyToExisitAnywhereInTheSystemAsVariableName'.]. Smalltalk garbageCollect. Smalltalk fixObsoleteReferences.
Running "Smalltalk shrink" then complains about two obsolete behaviours, and I this is a bug with Installer. If I just close the debugger and inspector, collect garbage and then run "SystemNavigation default obsoleteBehaviors" I get an empty array.
So it looks like the shrink works. It doesn't do much, though. My image goes from 20.9MB, down to 20.3MB.
and (just to check) you've already done Smalltalk unloadReloadablePackages? I managed to get down to a 12 Mb minimal trunk but I had to hack fix a lot of MNUs. Basically we have work to do to make those packages really unload.
Colin
On Mon, Jan 6, 2014 at 9:15 PM, Eliot Miranda eliot.miranda@gmail.comwrote:
So it looks like the shrink works. It doesn't do much, though. My image
goes from 20.9MB, down to 20.3MB.
and (just to check) you've already done Smalltalk unloadReloadablePackages? I managed to get down to a 12 Mb minimal trunk but I had to hack fix a lot of MNUs. Basically we have work to do to make those packages really unload.
Yup, #unloadReloadablePackages is part of #shrink. I was able to get down to about 19MB with no problems by unloading test packages. When I moved on to unloading production code that I don't need, I started getting MNUs too. I'll keep hacking at it until I see diminishing returns.
Thanks!
Colin
Don't forget there is no requirement to shrink an image along package boundaries. Did you try, for example, removing TestCase and all subclasses? That would cut across package boundaries but so what?
You can't unload Morphic but I'll bet you could dump a whole host of Morph subclasses. PaintBoxMorph, BouncingAtomsMorph, SoundRecorder, WaveEditor, PianoKeyboard, ScorePlayer, Storyboard, EventRecorder, Kedama and subclasses, etc., etc. etc.
I think "running with a modified system" is one of Smalltalk's greatest and least appreciated strengths.
On Tue, Jan 7, 2014 at 7:27 AM, Colin Putney colin@wiresong.com wrote:
On Mon, Jan 6, 2014 at 9:15 PM, Eliot Miranda eliot.miranda@gmail.com wrote:
So it looks like the shrink works. It doesn't do much, though. My image goes from 20.9MB, down to 20.3MB.
and (just to check) you've already done Smalltalk unloadReloadablePackages? I managed to get down to a 12 Mb minimal trunk but I had to hack fix a lot of MNUs. Basically we have work to do to make those packages really unload.
Yup, #unloadReloadablePackages is part of #shrink. I was able to get down to about 19MB with no problems by unloading test packages. When I moved on to unloading production code that I don't need, I started getting MNUs too. I'll keep hacking at it until I see diminishing returns.
Thanks!
Colin
On Tue, Jan 7, 2014 at 11:40 AM, Chris Muller asqueaker@gmail.com wrote:
Don't forget there is no requirement to shrink an image along package boundaries. Did you try, for example, removing TestCase and all subclasses? That would cut across package boundaries but so what?
I left TestCase in place, but I did try removing all subclasses. That led to an emergency evaluator. :-)
It turns out I was mistaken. "Smalltalk unloadReloadablePackages" wasn't actually working, it bailed after the first few packages because it calls #fixObsoleteReferences after unloading a package, which raises an error if there are obsolete classes.
Now that I've got that sorted out, I can reliably shrink to a 11.3MB image using the attached script.
There's one oddity in that script. I had to patch SystemNavigation>>allObjectsDo:, because I was getting a #shouldNotImplement error from the SmallInteger implementation of #nextObject. Somehow, scanning the heap got to the end without encountering the sentinel object created at the top of #allObjectsDo:, and #nextObject answered 0. I'm not sure what to make of that.
Anyway, the script suggests a few fixes that should go into trunk before release.
Colin
On 7 January 2014 17:32, Colin Putney colin@wiresong.com wrote:
On Tue, Jan 7, 2014 at 11:40 AM, Chris Muller asqueaker@gmail.com wrote:
Don't forget there is no requirement to shrink an image along package boundaries. Did you try, for example, removing TestCase and all subclasses? That would cut across package boundaries but so what?
I left TestCase in place, but I did try removing all subclasses. That led to an emergency evaluator. :-)
It turns out I was mistaken. "Smalltalk unloadReloadablePackages" wasn't actually working, it bailed after the first few packages because it calls #fixObsoleteReferences after unloading a package, which raises an error if there are obsolete classes.
Now that I've got that sorted out, I can reliably shrink to a 11.3MB image using the attached script.
There's one oddity in that script. I had to patch SystemNavigation>>allObjectsDo:, because I was getting a #shouldNotImplement error from the SmallInteger implementation of #nextObject. Somehow, scanning the heap got to the end without encountering the sentinel object created at the top of #allObjectsDo:, and #nextObject answered 0. I'm not sure what to make of that.
Anyway, the script suggests a few fixes that should go into trunk before release.
I notice for starters that you #zapMVCProjects _after_ unloading ST80. Did you move that specifically, or was that just happenstance from folding #unloadReloadablePackages into the shrink script?
Regarding this guy:
names do: [:pkgName | (PackageInfo named: pkgName) classes do: [:ea | ea unload]]. names do: [:pkgName | Installer mc unload: pkgName].
That's pretty much what I was thinking of doing inside MC's #basicLoad. I hesitated because it involves sending #unload twice to every class, and doubted whether general implementations of #unload were idempotent.
But I guess it must have worked out OK for you during the script?
frank
Colin
On Tue, Jan 7, 2014 at 2:28 PM, Frank Shearar frank.shearar@gmail.comwrote:
I notice for starters that you #zapMVCProjects _after_ unloading ST80. Did you move that specifically, or was that just happenstance from folding #unloadReloadablePackages into the shrink script?
No, I think the zapping happens while ST80 is still there. I moved the list of packages to unload to the top, but left the actual unloading in place.
Regarding this guy:
names do: [:pkgName | (PackageInfo named: pkgName) classes do: [:ea | ea unload]]. names do: [:pkgName | Installer mc unload: pkgName].
That's pretty much what I was thinking of doing inside MC's #basicLoad. I hesitated because it involves sending #unload twice to every class, and doubted whether general implementations of #unload were idempotent.
But I guess it must have worked out OK for you during the script?
It seems to. But I thought the problem was that #unload has no effect, because the method has been removed by the time message is sent, and we fall back to the superclass noop. I originally had one loop the first sent #unload to all classes, than unloaded the package, but I found that was more sensitive to the order of the package names. The unload method would fail because it depended on something that's already gone. Two loops seems more robust.
I'm still working on it—down to about 10MB now. Will post again when I declare victory.
Colin
John McIntosh did some shrinking work many moons ago when working on Squeak for iOS. Perhaps this old email could help with your shrinking? Maybe there was further work after the email.
Ken G. Brown
Date: Wed, 11 Feb 2009 21:13:50 -0800 From: John M McIntosh johnmci@smalltalkconsulting.com Subject: Re: [squeak-dev] ditching Monticello objects. To: Keith Hodges keith_hodges@yahoo.co.uk Cc: The general-purpose Squeak developers list squeak-dev@lists.squeakfoundation.org Message-ID: B07FF75B-07C4-4C3F-ABB9-E6397B70AC73@smalltalkconsulting.com Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes
Ok, well I did
I've been collecting lists of pruning methods so..
ScrollBar initializeImagesCache. GradientFillStyle initPixelRampCache. NaturalLanguageFormTranslator classPool at: #CachedTranslations put: nil. NaturalLanguageTranslator resetCaches. PartsBin clearThumbnailCache. PaintBoxMorph classPool at: #ColorChart put: nil. PaintBoxMorph classPool at: #Prototype put: nil. ImageMorph classPool at: #DefaultForm put: (Form extent: 1@1 depth: 1). Utilities classPool at: #ScrapsBook put: nil. Project allInstancesDo: [ :each | each setThumbnail: nil ]. ScriptingSystem stripGraphicsForExternalRelease. ProjectHistory currentHistory initialize. Utilities zapUpdateDownloader. Smalltalk forgetDoIts. Behavior flushObsoleteSubclasses. CommandHistory allInstancesDo: #initialize. ChangeSorter removeChangeSetsNamedSuchThat: [ :each | true ]. ChangeSet resetCurrentToNewUnnamedChangeSet. MethodChangeRecord allInstancesDo: [ :x | x noteNewMethod: nil ]. RequiredSelectors initialize. ProvidedSelectors initialize. LocalSends initialize. SendCaches initializeAllInstances. Utilities cleanseOtherworldlySteppers. Smalltalk organization removeEmptyCategories. Browser initialize. SMSqueakMap default purge. SystemBrowser removeObsolete. TheWorldMenu removeObsolete. AppRegistry removeObsolete. FileServices removeObsolete. MCFileBasedRepository flushAllCaches. MCDefinition clearInstances. Undeclared removeUnreferencedKeys. Smalltalk flushClassNameCache. 3 timesRepeat: [ Smalltalk garbageCollect. Symbol compactSymbolTable ]. Set rehashAllSets. Smalltalk garbageCollect.
I added these ones.
ChangeSorter initializeChangeSetCategories. MCWorkingCopy inspect. MCRepositoryGroup inspect. MCCacheRepository inspect.
and cleaned up the class instance variables & any class vars via the inspect.
That removed all the MC packages and MC http repositories from the MC Browser
gave me back 4 megabytes of image space.
Well brute force, still 4 mb wonderful to get back this late in the project.
On 11-Feb-09, at 6:18 PM, Keith Hodges wrote:
John M McIntosh wrote:
I'm building an image for a limited memory hardware platform.
At the point here where I want to *deploy* things and I can see that various parts of Monticello are consuming well over a megabyte of memory to retain MCVersionInfo instances, MCMethodDefinition(s), time stamps, uuids, etc etc
I'm wondering if anyone has some code to strip all that out thus returning I suspect a couple of MB back for more constructive usage?
You may want to look into the cleanUp/freeSomeSpace conventions. MC1.5 has a few implemented. There are many more available from http://bugs.squeak.org/view.php?id=7244
Keith
-- = = = ======================================================================== John M. McIntosh johnmci@smalltalkconsulting.com Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com = = = ========================================================================
On Jan 7, 2014, at 12:38 PM, Colin Putney colin@wiresong.com wrote:
On Tue, Jan 7, 2014 at 2:28 PM, Frank Shearar frank.shearar@gmail.com wrote:
I notice for starters that you #zapMVCProjects _after_ unloading ST80. Did you move that specifically, or was that just happenstance from folding #unloadReloadablePackages into the shrink script?
No, I think the zapping happens while ST80 is still there. I moved the list of packages to unload to the top, but left the actual unloading in place.
Regarding this guy:
names do: [:pkgName | (PackageInfo named: pkgName) classes do: [:ea | ea unload]]. names do: [:pkgName | Installer mc unload: pkgName].
That's pretty much what I was thinking of doing inside MC's #basicLoad. I hesitated because it involves sending #unload twice to every class, and doubted whether general implementations of #unload were idempotent.
But I guess it must have worked out OK for you during the script?
It seems to. But I thought the problem was that #unload has no effect, because the method has been removed by the time message is sent, and we fall back to the superclass noop. I originally had one loop the first sent #unload to all classes, than unloaded the package, but I found that was more sensitive to the order of the package names. The unload method would fail because it depended on something that's already gone. Two loops seems more robust.
I'm still working on it—down to about 10MB now. Will post again when I declare victory.
Colin
On Tue, Jan 7, 2014 at 10:44 PM, Ken G. Brown kbrown@mac.com wrote:
John McIntosh did some shrinking work many moons ago when working on Squeak for iOS. Perhaps this old email could help with your shrinking? Maybe there was further work after the email.
Nice! That shaved off another 700K, and brought the final shrink below 10MB.
Thanks.
Se also Pavel Krivaneks changes; http://forum.world.st/SqueakCore-td4661356.html
Cheers, Karl
On Thu, Jan 9, 2014 at 6:02 PM, Colin Putney colin@wiresong.com wrote:
On Tue, Jan 7, 2014 at 10:44 PM, Ken G. Brown kbrown@mac.com wrote:
John McIntosh did some shrinking work many moons ago when working on Squeak for iOS. Perhaps this old email could help with your shrinking? Maybe there was further work after the email.
Nice! That shaved off another 700K, and brought the final shrink below 10MB.
Thanks.
On 9 January 2014 17:33, karl ramberg karlramberg@gmail.com wrote:
Se also Pavel Krivaneks changes; http://forum.world.st/SqueakCore-td4661356.html
I haven't had time to complete the job, but a lot of the recent work around shrinking, unloading and the like pretty much came either from me rediscovering Pavel's tricks, or me copying Pavel's tricks over to the image.
frank
Cheers, Karl
On Thu, Jan 9, 2014 at 6:02 PM, Colin Putney colin@wiresong.com wrote:
On Tue, Jan 7, 2014 at 10:44 PM, Ken G. Brown kbrown@mac.com wrote:
John McIntosh did some shrinking work many moons ago when working on Squeak for iOS. Perhaps this old email could help with your shrinking? Maybe there was further work after the email.
Nice! That shaved off another 700K, and brought the final shrink below 10MB.
Thanks.
On 1/9/14, Frank Shearar frank.shearar@gmail.com wrote:
On 9 January 2014 17:33, karl ramberg karlramberg@gmail.com wrote:
Se also Pavel Krivaneks changes; http://forum.world.st/SqueakCore-td4661356.html
I haven't had time to complete the job, but a lot of the recent work around shrinking, unloading and the like pretty much came either from me rediscovering Pavel's tricks, or me copying Pavel's tricks over to the image.
frank
Excellent, thank you all and in particular, you, Frank.
Hannes
Colin
at the start of this thread (6th January) you said that you do
Smalltalk shrinkAndCleanDesktop
and later and after some fixes (to the image and/or the trunk?) you report that the resulting image is below 10MB.
As of now is
Smalltalk shrinkAndCleanDesktop
all that I need to do or do I need to issue other commands?
Regards --Hannes
On 1/10/14, H. Hirzel hannes.hirzel@gmail.com wrote:
On 1/9/14, Frank Shearar frank.shearar@gmail.com wrote:
On 9 January 2014 17:33, karl ramberg karlramberg@gmail.com wrote:
Se also Pavel Krivaneks changes; http://forum.world.st/SqueakCore-td4661356.html
I haven't had time to complete the job, but a lot of the recent work around shrinking, unloading and the like pretty much came either from me rediscovering Pavel's tricks, or me copying Pavel's tricks over to the image.
frank
Excellent, thank you all and in particular, you, Frank.
Hannes
On Fri, Jan 10, 2014 at 3:52 AM, H. Hirzel hannes.hirzel@gmail.com wrote:
Colin
at the start of this thread (6th January) you said that you do
Smalltalk shrinkAndCleanDesktopand later and after some fixes (to the image and/or the trunk?) you report that the resulting image is below 10MB.
As of now is
Smalltalk shrinkAndCleanDesktop
all that I need to do or do I need to issue other commands?
No. I started with that, but it doesn't quite work, so I extracted it into a script. I've been tweaking the script to fix issues as they come up, and to customize the shrink to the needs of my project. I'm pushing generally useful fixes back into trunk, but it's not completely done yet.
I'm also finding that every time I update to a new trunk image from build.squeak.org, I run into new issues. :-)
Colin
On 10 January 2014 14:38, Colin Putney colin@wiresong.com wrote:
On Fri, Jan 10, 2014 at 3:52 AM, H. Hirzel hannes.hirzel@gmail.com wrote:
Colin
at the start of this thread (6th January) you said that you do
Smalltalk shrinkAndCleanDesktopand later and after some fixes (to the image and/or the trunk?) you report that the resulting image is below 10MB.
As of now is
Smalltalk shrinkAndCleanDesktop
all that I need to do or do I need to issue other commands?
No. I started with that, but it doesn't quite work, so I extracted it into a script. I've been tweaking the script to fix issues as they come up, and to customize the shrink to the needs of my project. I'm pushing generally useful fixes back into trunk, but it's not completely done yet.
I'm also finding that every time I update to a new trunk image from build.squeak.org, I run into new issues. :-)
I'm hoping that's a good thing :/ Chris & I replaced the base CI image, by the way. So at least your starting point nowadays will have clean packages (even if it's not semi-pre-slimmed). I'll take another run at the the minimal-base-image-rehydrated-on-CI approach in the 4.6 cycle.
frank
Colin
I'm hoping that's a good thing :/ Chris & I replaced the base CI image, by the way. So at least your starting point nowadays will have clean packages (even if it's not semi-pre-slimmed). I'll take another run at the the minimal-base-image-rehydrated-on-CI approach in the 4.6 cycle.
Ah, good idea. For 4.5, let's let the final deployment image to be one which has never undergone a shrink / rehydration. If we want to risk that for 4.6 release then put out our *second* 4.6 alpha image be one of those rehydrated so it can endure a full release-cycle of testing including under our personal projects.
On 1/9/14 3:07 PM, "Frank Shearar" frank.shearar@gmail.com wrote:
On 9 January 2014 17:33, karl ramberg karlramberg@gmail.com wrote:
Se also Pavel Krivaneks changes; http://forum.world.st/SqueakCore-td4661356.html
I haven't had time to complete the job, but a lot of the recent work around shrinking, unloading and the like pretty much came either from me rediscovering Pavel's tricks, or me copying Pavel's tricks over to the image.
frank
I always wish Pavel work was taked into Squeak, but we have a champion shrink image and is Cuis reduced.
You could have a 2 mb .image Morphic enabled.
Cheers, Karl
On Thu, Jan 9, 2014 at 6:02 PM, Colin Putney colin@wiresong.com wrote:
On Tue, Jan 7, 2014 at 10:44 PM, Ken G. Brown kbrown@mac.com wrote:
John McIntosh did some shrinking work many moons ago when working on Squeak for iOS. Perhaps this old email could help with your shrinking? Maybe there was further work after the email.
Nice! That shaved off another 700K, and brought the final shrink below 10MB.
Thanks.
On Tue, Jan 7, 2014 at 11:40 AM, Chris Muller asqueaker@gmail.com wrote:
Don't forget there is no requirement to shrink an image along package boundaries. Did you try, for example, removing TestCase and all subclasses? That would cut across package boundaries but so what?
I left TestCase in place, but I did try removing all subclasses. That led to an emergency evaluator. :-)
How did you try removing all subclasses? I wasn't sure how the system would respond to removing a class with subclasses, so I removed leaf subclasses first, which worked the first time.
[(TestCase allSubclasses select: [ : each | each subclasses isEmpty ]) do: [ : each | each removeFromSystem: false ]. TestCase allSubclasses size > 0 ] whileTrue
It turns out I was mistaken. "Smalltalk unloadReloadablePackages" wasn't actually working, it bailed after the first few packages because it calls #fixObsoleteReferences after unloading a package, which raises an error if there are obsolete classes.
Now that I've got that sorted out, I can reliably shrink to a 11.3MB image using the attached script.
There's one oddity in that script. I had to patch SystemNavigation>>allObjectsDo:, because I was getting a #shouldNotImplement error from the SmallInteger implementation of #nextObject. Somehow, scanning the heap got to the end without encountering the sentinel object created at the top of #allObjectsDo:, and #nextObject answered 0. I'm not sure what to make of that.
Anyway, the script suggests a few fixes that should go into trunk before release.
Yes. Incidentally, sharing .st scripts through e-mail, Squeak can never seem to parse them when the attachment is downlaoded to another platform. I think because the email client treats it as "text" needing LE conversoins or something. Could you gzip your .st file and so it will be treated as binary, then I can look at it.
OR, if you want to put it into trunk I'll just see it there.
thanks!
Colin
Hi Colin--
I think the best way to shrink is for the garbage collector to do it. There's an alternate version of the GC in Spoon[1], invoked with Interpreter>>primitiveSnapshotWithoutStaleMethods. It sets a mark bit on all the methods associated with contexts in extant processes, along with any other methods which have run (for example, by running unit tests). Then it treats all other methods as garbage in the pre-snapshot GC.
This leads to a chain reaction; the methods that aren't marked are usually the only things referring to their literals (including classes). The process is immediate, and requires no knowledge of what's being thrown away. The only difference between producing a minimal system (currently 1kB) and a larger one (e.g., the Spoon development base system at 300 kB) is how many methods you mark in advance by running them.
-C
[1] http://netjam.org/spoon/releases/current
-- Craig Latta www.netjam.org/resume +1 510 984 8117 (Skype rings this until 31 January 2014)
On 7 January 2014 02:33, Craig Latta craig@netjam.org wrote:
Hi Colin--
I think the best way to shrink is for the garbage collector to doit. There's an alternate version of the GC in Spoon[1], invoked with Interpreter>>primitiveSnapshotWithoutStaleMethods. It sets a mark bit on all the methods associated with contexts in extant processes, along with any other methods which have run (for example, by running unit tests). Then it treats all other methods as garbage in the pre-snapshot GC.
Craig, how difficult would it be to get the necessary VM changes for this feature into the main VMs?
frank
Hi Frank--
...how difficult would it be to get the necessary VM changes for this feature into the main VMs?
It would be easy if the Unix VM build instructions were accurate. :) I wrote a separate message to vm-dev with details. The changes are at [1]. Please feel free to integrate them while I do, please let me know if you get somewhere.
thanks,
-C
[1] http://tinyurl.com/p999omz
-- Craig Latta www.netjam.org/resume +1 510 984 8117 (Skype rings this until 31 January 2014)
squeak-dev@lists.squeakfoundation.org
-
Chris Muller -
Colin Putney -
Craig Latta -
Edgar De Cleene -
Eliot Miranda -
Frank Shearar -
H. Hirzel -
karl ramberg -
Ken G. Brown -
Tobias Pape