Out of space + other flakiness
Bob Arning
arning at charm.net
Sat Jun 30 13:50:13 UTC 2001
Hi Ross,
On Fri, 29 Jun 2001 22:32:18 -0700 Ross Boylan <RossBoylan at 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
More information about the Squeak-dev
mailing list
|