Folks -
A week or so ago, I sent out a message describing a technique for extracting segments from the Squeak image. What I want to know is,
Does anyone know of such a technique having being used previously?
I figure it must be known, but I have certainly never heard of it. Please reply directly to me.
To recap, here's how it works:
1. Mark the root (or roots) of the subtree desired.
2. Do a GC mark pass. SInce this stops at any marked objects, the subtree will be unmarked, "in the shadow" of its roots.
3. Copy the roots and the unmarked subtree into a byteArray (the image segment) Relocate internal pointers as you go Copy external pointers into a table of outpointers.
Reinstalling a segment is incredibly simple -- all you do is remap any pointers in one pass and throw away the byteArray header!
Thanks - Dan
PS... Ted and I have just completed an implementation and it is great. (It will be out in updates and release 2.4 within a week). It can trace and copy a 520kb tree of over 15000 objects in about 390ms. Used for deepCopy, it is about 20 times faster than what we do currently. Used to swap segments in and out, it finally offers a realistic vehicle for breaking down Squeak's monolithic images.
It's even faster than you would guess from the above. There is a fixed overhead for the full GC mark and unmark. This is 350ms on my machine (could surely be improved). It can then copy out the 520kb segment or reinstall it in about 40ms either way.
Since the the preferences control panel has outgrown my screen I have made it scrolling. See http://macos.tuwien.ac.at/Squeak/ScrollingPrefs.st.
In the process a question arose: Is ScrollPane intended to be an abstract superclass or not. If not the "extent:" method probably should include a "setScrollDeltas" call (my solution, PluggableListMorph>extent: could be yanked), otherwise an additional subclass would be necessary.
Enjoy, Georg ---- Dipl.Ing. Georg Gollmann TU-Wien, Zentraler Informatikdienst
phon:(+43-1) 58801 - 42022 fax: (+43-1) 58801 - 42099 mail:gollmann@zid.tuwien.ac.at http://macos.tuwien.ac.at/Gollmann.html
On Mon, 26 Apr 1999, Georg Gollmann wrote:
Since the the preferences control panel has outgrown my screen I have made it scrolling. See http://macos.tuwien.ac.at/Squeak/ScrollingPrefs.st.
Looks good! It was getting too tall for me, too...
(Eventually, it would be nice for the preferences panel to be grouped somehow, with a notebook widget for example. I guess someone needs to create a notebook widget first, though, or some other clever grouping widget.)
In the process a question arose: Is ScrollPane intended to be an
abstract
superclass or not. If not the "extent:" method probably should include a "setScrollDeltas" call (my solution, PluggableListMorph>extent: could be yanked), otherwise an additional subclass would be necessary.
This issue is due to the sized scrollbar change I made (which was added to the base image a couple of months ago), which required that setScrollDeltas be called from the various extent: methods. Basically, I sort of assumed ScrollPane was an abstract superclass, but now that I think about it, there's no reason that it must be abstract.
You're right, ScrollPane>>extent: should include a call to "setScrollDeltas", and PluggableListMorph>>extent: should be removed. I would go ahead and change the file-in on your webspace to remove PluggableListMorph>>extent:, so if the Squeak Team decides to incorporate your scrollable prefs change, they will get that fix as well. (Even if they don't add your change, the change to Scrollpane>>extent: and the removal of PluggableListMorph>>extent: should still be made.)
- Doug Way EAI/Transom Technogies, Ann Arbor, MI dway@eai.com, dway@mat.net http://www.transom.com
Smalltalk: Guaranteed Y2T Compliant
At 0:28 Uhr -0400 27.04.1999, Doug Way wrote:
On Mon, 26 Apr 1999, Georg Gollmann wrote:
Since the the preferences control panel has outgrown my screen I have made it scrolling. See http://macos.tuwien.ac.at/Squeak/ScrollingPrefs.st.
....
This issue is due to the sized scrollbar change I made (which was added to the base image a couple of months ago), which required that setScrollDeltas be called from the various extent: methods. Basically, I sort of assumed ScrollPane was an abstract superclass, but now that I think about it, there's no reason that it must be abstract.
You're right, ScrollPane>>extent: should include a call to "setScrollDeltas", and PluggableListMorph>>extent: should be removed. I would go ahead and change the file-in on your webspace to remove PluggableListMorph>>extent:, so if the Squeak Team decides to incorporate your scrollable prefs change, they will get that fix as well. (Even if they don't add your change, the change to Scrollpane>>extent: and the removal of PluggableListMorph>>extent: should still be made.)
Thanks for the background information. I have incorporated your suggestion in my fileIn.
Georg ---- Dipl.Ing. Georg Gollmann TU-Wien, Zentraler Informatikdienst
phon:(+43-1) 58801 - 42022 fax: (+43-1) 58801 - 42099 mail:gollmann@zid.tuwien.ac.at http://macos.tuwien.ac.at/Gollmann.html
squeak-dev@lists.squeakfoundation.org