Hi Ross,
On Fri, 29 Jun 2001 22:32:18 -0700 Ross Boylan RossBoylan@stanfordalumni.org wrote:
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.
Also quite useful is
PointerFinder on: <someObject>
This will trace <someObject> back to Smalltalk and open a window showing the links in the chain.
I thought the current VMs could grow as needed. I'm surprised to see that it apparently can't.
I *think* the Windows VM may be able to do that now, but I'm not really sure.
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.
Which OS is this?
TheWorldMenu was pointing to one of the projects I hand't used much.
Hmm.. doesn't sound like a good thing. I'll take a look at it.
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.
I thought we had this one fixed, but your example gives me the clues I need. I'll put out an update to fix it. Thanks.
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
Is this a clean image or one you have added stuff to? I ask because you have many more Strings than I do (although not that much more in terms of space). Have you tried
ChangeSet allInstancesDo: [:cs | cs zapHistory]
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)?
One use of ByteArrays is to hold the compressed version of Forms which have been hibernated. One technique I use in rooting out these mysteries is something like:
PointerFinder on: (ByteArray allInstances asSortedCollection: [ :a :b | a size > b size]) first
I'm guessing the strings are source code.
Maybe literals in methods, but the source itself is usually only found on disk. The exceptions would be any browsers you have open, etc. Some interesting things to inspect:
(String allInstances collect: [ :x | x size]) asBag
(String allInstances select: [ :x | x size > 1000])
Cheers, Bob
At 09:50 AM 6/30/01 -0400, Bob Arning wrote:
Hi Ross,
On Fri, 29 Jun 2001 22:32:18 -0700 Ross Boylan RossBoylan@stanfordalumni.org wrote:
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.
Also quite useful is
PointerFinder on: <someObject>
This will trace <someObject> back to Smalltalk and open a window showing the links in the chain.
Beautiful! Sounds like just what I need. Can it cope with multiple paths and loops?
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.
Which OS is this?
Debian GNU/Linux, kernel 2.4.2. Mostly "woody" level packages.
TheWorldMenu was pointing to one of the projects I hand't used much.
Hmm.. doesn't sound like a good thing. I'll take a look at it.
I thought this might be the result of some interrupted processing because of the memory problems, rather than a bug in code. E.g., I exited that project but ran out of memory before the project in TheWorldMenu was updated. Although I guess I'd expect the project to be reset every time I switched projects...
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
Is this a clean image or one you have added stuff to? I ask because you have many more Strings than I
The image is far from clean.
do (although not that much more in terms of space). Have you tried
ChangeSet allInstancesDo: [:cs | cs zapHistory]
Just did it. I now see Smalltalk bytesLeftString '4,284,616 bytes (internal) 193,700,040 bytes (physical) 523,161,800 bytes (total) ' Before I got '5,245,932 bytes available' However, I'm now on Win32 and the "before" is Debian. I can't tell if this is progress. Based on the total space use from printSpaceAnalysis, I gained almost 2Mg..
And here's the new report: Class code space # instances inst space percent String 16824 63818 2648056 20.3 CompiledMethod 7578 39332 2397428 18.4 Array 1478 39769 1742016 13.3 Bitmap 3277 765 1572108 12.0 Symbol 3610 32913 663370 5.1 ByteArray 3192 447 606958 4.6 ChangeRecord 1250 13593 489348 3.7 MethodDictionary 1826 3568 387532 3.0 WeakArray 711 54 346680 2.7 Total 4897893 297339 13059104 96.9
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)?
One use of ByteArrays is to hold the compressed version of Forms which have been hibernated. One technique I use in rooting out these mysteries is something like:
PointerFinder on: (ByteArray allInstances asSortedCollection: [ :a :b | a size > b size]) first
I'm guessing the strings are source code.
Maybe literals in methods, but the source itself is usually only found on disk. The exceptions would be any browsers you have open, etc. Some interesting things to inspect:
(String allInstances collect: [ :x | x size]) asBag (String allInstances select: [ :x | x size > 1000])
Most of the biggest strings apppear to be C source code. I have 967 0 length strings.
Cheers, Bob
Thanks very much.
squeak-dev@lists.squeakfoundation.org