Path: utzoo!utgpu!news-server.csri.toronto.edu!rutgers!tut.cis.ohio-state.edu!abvax!iccgcc!klimas
From: klimas@astro.pc.ab.com
Newsgroups: comp.lang.smalltalk
Subject: Re: limitation for amount of Symbol instances??!!
Message-ID: <505.26cbd47a@astro.pc.ab.com>
Date: 17 Aug 90 16:26:50 GMT
References: <90228.171958MUHRTH@DB0TUI11.BITNET>
Lines: 33

In article <90228.171958MUHRTH@DB0TUI11.BITNET>, MUHRTH@tubvm.cs.tu-berlin.de (Thomas Muhr) writes:
> We just found our limits !-)
	What you mean "our limits"!?
> If what we found is true, there is really a severe limitation of ST V
> for large applications: well known from the manual is the fact, that
> instances of class Symbol are excluded from garbage collection and that -
> from time to time - you have to manually recollect space by issuing
> Symbol purgeUnusedSymbols.
	The Symbols dictionary being a global variable is always going to
	hang around the system.  That's the way it was designed to work.
> But nowhere have I found a note about the upper limit for Symbols: In ours
> it is 5157, despite enough memory left for objects (1.5 MB unusedMemory).
	Try reading Appendix 3:Pointer Table on page 467 of the manual.  There
	is a discussion of parameters that can be adjusted to modify those 
	limits.
> We have to redesign the system to never using any "asSymbol" or the like
> for Strings. 
	Hmmmmm?  I wonder about this??!
> The number of Symbols includes every classname and selector in
> the system, so that you have to be careful of how many methods you create,
> which contrasts the philosophy of OOP significantly.
	Normally one can create quite a bit of code without worrying about
	it.  If it does become a problem, then purge the table.  I have 
	used /V quite a bit and have rarely bumped into this.  If one uses
	a code management system (such as the Carleton App Manager) to
	periodically rebuild the system from a virgin image then it is
	even less likely.

> Our only hope is that some "goodie" (or baddy ?) has modified the complicated
> management of objects in an unpleasant way.
	If one is building a big application then you should use /V286 or /V-PM
	which raise the limit to some level that we have never encountered 
	problems with.