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