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

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]) 


More information about the Squeak-dev mailing list