Sept 10, 2001.	Tips and Thoughts

Visualwork Symbols

In case anyone is wondering VisualWorks uses an Array of WeakArrays to ensure Symbols are unique, versus a single dictionary. Because it uses a Weak object when the last reference to the symbol disappears as part of a GC event, the Symbol and the reference to the Symbol goes away... In VisualWorks the WeakArray slot gets the value 0 which is a clue to which reference went away.(Self Cleaning). Later when we need to deposit a reference to a new symbol in the WeakArray we look for a slot pointing to 0, if not found we grow the WeakArray. Which WeakArray to use is based on a hash of the string plus information about the number of existing weak arrays. Is this better faster? Hard to say.
 
However the structure required to track symbols still grows to match the peak Symbol usage, but as you delete Symbols the ByteSymbol or TwoByteSymbol objects will disappear saving some space. Of course you can invoke Symbol initialize to rehash/rebuild the structure if you added say a million symbols then deleted them all and were concerned about space. (maybe having a million symbols might need a rehash due to concerns about probes into the structure?, more symbols means slower asSymbol since we walk the candidate WeakArray looking for the symbol)
 
Symbols can save space I just did some tuning work with an unnamed vendor package that stored field identifiers as character strings. Problem was that when we scaled up to hundred of thousands of objects these field identifiers consumed megabytes of memory! Changing the code to have it NOT return a copy of the field identifier string help reduce the memory consumption problem, but usage of Symbols here would have helped both memory and performance.
 
Note single byte symbols are handled differently.

Suspend/Resume gotha.

First, examine the code of ProcessorController until you think you understand it. It has one instance, stored in the global Processor, that is keeping references to these Processes you assumed would go away when *you* stopped referring to them. They are arranged in queues, ordered by priority.
 
As a side point there is a litte gotha here. If you don't have a strong reference to your process elsewhere, and if you suspend the process, versus killing it, all the ProcessController does is remove it from the queue. However this might be your last strong reference to the process and it will "shortly" be GCed and dissappear. {Yes this happened to me, very very agravating}
 
Why suspend. Well with a little work you can write a kill/freeze method that targets your processes, suspends them, then invokes a debugger on each process's suspended context. If you've got an ugly multiprocess conflict bug this code can be very helpful.

VisualWorks Command line parms

> Can anybody tell me what the command line options for launching Parc's
> VisualWorks (either version 2.5 or 2.0)?
>
vw -v image    gives version number information
vw -h 5 image  adds 5mb of memory to the heap (I assume the C heap for DLL/C?)
vw -o 5 image  ? Don't have docs on what this does, anyone know?

> I'm running VisualWorks 2.52 on WinNT 4.0.
> My problem is that I get this nasty message ('fatal smalltalk error: out of memory'),
 
Well there are a few bugs, and some changes to memory space allocations if done correctly and done to avoid VM bugs will help. However first let me suggest you visit
 
MemoryPolicy>>makeSpaceFor:
 
and delete or comment out the line
 
(memoryStatus largeBytes - memoryStatus largeUsedBytes) > (bytesWanted + memoryStatus bytesPerLTE) ifTrue: [^self].

{Please note this is fixed in 3.1. In 3.1 they now have makeSpaceFor:memoryTypeSymbol: and pass in the space type. The above check is then and: with #largeSpace so the check only affects an allocation for Large Space. In 2.5 and below the problem was that if you allocated a non-large space object, then the check above would cause a problem since it considered Large Space in its calculations. Problem is that your object can't be allocated in Large Space. The expansion code would say "Hey lots of space on Large Space", but the reallocation would then fail. The logic is explained in detail in my paper}

I discovered a problem with meta-classes.

Ever see a allocation failure for stable frame?

You say your image crashs after 24.86 days?

A Mac allocation problem? Out of memory but why?

Finally 99 bottles of beers on the wall, for which I take no credit.