On Fri, 29 Jun 2001 16:13:41 -0700 Ross Boylan RossBoylan@stanfordalumni.org wrote:
I've hunted around for tools or convenience methods that would give me a more complete picture of object memory--all I have now is the # free bytes ( '1,148,708 bytes available'). I'd like to know how much memory it thinks its using, the amount each class's instances are taking and such.
Ross,
Try
Smalltalk spaceTallyTo: 'somefile.txt'. or Smalltalk printSpaceAnalysis: 1000 on: 'STspace.text0'.
BTW, 1.1 meg free is not a lot.
Cheers, Bob
You may also want to assign more memory to Squeak when you run it. There's an item on the Squeak FAQ ( http://minnow.cc.gatech.edu/squeak/squeakFaq ) which explains how to assign more memory to Squeak upon startup... it varies depending on your platform.
- Doug Way dway@riskmetrics.com
On Friday, June 29, 2001, at 09:57 PM, Bob Arning wrote:
On Fri, 29 Jun 2001 16:13:41 -0700 Ross Boylan RossBoylan@stanfordalumni.org wrote:
I've hunted around for tools or convenience methods that would give me a more complete picture of object memory--all I have now is the # free bytes ( '1,148,708 bytes available'). I'd like to know how much memory it thinks its using, the amount each class's instances are taking and such.
Ross,
Try
Smalltalk spaceTallyTo: 'somefile.txt'. or Smalltalk printSpaceAnalysis: 1000 on: 'STspace.text0'.
BTW, 1.1 meg free is not a lot.
Cheers, Bob
Thanks. I think things are back under control now. So the rest of this is making conversation.
A handy thing I found was "Smalltalk pointersTo:" to trace object references back.
I killed almost all the projects, most of which were not reachable through clicking on navigator windows. (They did show on the menu). I now have 5 Mg free (which still seems kind of small), and the image saves to a 14Mg file. This included killing the Intro to Squeak project and its subprojects.
I thought the current VMs could grow as needed. I'm surprised to see that it apparently can't.
Among the oddities encountered: I frequently ended up with two squeak processes running when it hung. I was a bit surprised to find it launching separate processes.
TheWorldMenu was pointing to one of the projects I hand't used much.
I got into some very weird debugger states, where it apparently switched the identifiers of variables. The code ran OK when not in the debugger. While inspecting the results of Project allInstances I entered the following in the bottom pane: #(2 11 12 13 14) do: [:i | |aProject| Transcript show: i printString; tab. aProject _ self at: i. self halt. Transcript show: aProject printString; cr. ProjectHistory forget: aProject. Project deletingProject: aProject.].
When I looked in the debugger, i contained a project, and aProject had the number 2 in it--the reverse of what should have been. The code also acted this way--when I went forward I got errors because objects weren't the right types. When I removed the halt, the sensible values came out on the transcript, and the most of the requested deletions did occur.
Some object sizing below. On Fri, Jun 29, 2001 at 09:57:33PM -0400, Bob Arning wrote:
On Fri, 29 Jun 2001 16:13:41 -0700 Ross Boylan RossBoylan@stanfordalumni.org wrote:
I've hunted around for tools or convenience methods that would give me a more complete picture of object memory--all I have now is the # free bytes ( '1,148,708 bytes available'). I'd like to know how much memory it thinks its using, the amount each class's instances are taking and such.
Ross,
Try
Smalltalk spaceTallyTo: 'somefile.txt'. or Smalltalk printSpaceAnalysis: 1000 on: 'STspace.text0'.
BTW, 1.1 meg free is not a lot.
Cheers, Bob
Here's my top printSpaceAnalysis before: Class code space # instances inst space percent String 16824 69965 3482093 18.1 ByteArray 3192 559 3276681 17.0 CompiledMethod 7578 41735 2691360 14.0 Array 1494 48182 2288068 11.9 Bitmap 3277 1526 2025812 10.5 Symbol 3610 32939 663867 3.5
and after
String 16824 68212 3365324 22.5 CompiledMethod 7578 41715 2690236 18.0 Array 1478 42607 2139148 14.3 Bitmap 3277 825 1784456 12.0 Symbol 3610 32937 663822 4.4
By far the biggest win was ByteArray, which lost over 2.6Mg of memory in 92 objects. What were those likely holding? bit maps (not the class, but something related)? I'm guessing the strings are source code. I also almost halved the number of Points and Rectangles.
squeak-dev@lists.squeakfoundation.org