Building in the ability to change these tables at runtime would be an 
interesting, perhaps useful thing to do.

I'll just cherry pick the easy ones.

>On Sat, 16 Mar 2002, PhiHo Hoang wrote:
>
>>  My only concern was that how were the numbers arrived at for things
>>  like:
>
>  >		int atCache[65];
>
>AFAIK, This is an optimization; it doesn't affect correctness.  But,
>experimentation for different sizes might be fruitful.  Anyone know how
>much the atCache affects the runtime? I may get a chance to look at it.

A year ago I looked at this and from a note I sent to Dan I'll quote:
"I noted that in lookupInMethodCacheSelclass, the number of calls was 
about 50 million,and cache hits: 20M on probe1, 16M on probe2, 11M on 
probe3 and 1.8M not found

BTW I looked at atCache, but mmm 'since objects die young' found that 
over 70% of the at cache would be flushed at any given incremental GC 
event. (IE 70% of the time objects were in new space)."

>
>  >		int semaphoresToSignalA[501];
>>		int semaphoresToSignalB[501];
>
>Dunno about these. Would these be a limit on the maximum number of open
>sockets?

This is my change a few years back.
On the mac VM, semaphores for sockets can be signalled at interrupt 
time based on socket level interrupt driven routines running. When I 
rewrote the socket code I found the original semaphore logic would 
lose interrupts because of a race condition in the logic, also it was 
a single table with 25 entries. (Way too small)

Now the question was how to do this without using specialized OS 
locking, and not usually loose semaphore signals. After a bit of 
reading and thinking I came up with the solution to have two tables, 
one that is active queuing pending semaphores, the other table is 
being processed in checkForInterrupts.

So pushing a few dozen connections, moving 80Mbits a second (100Mb 
router) I found a 500mhz machine could only peak at 300 or so 
interrupts signals a second. Therefore I picked 500 as a reasonable 
solution. In the past checkfor interrupts would get called 200 times 
per second, now that could be as much as 333 times
per second, or even 1000 times per second depending on what is going 
on. So can you signal more than  500 interrupts in 1 to 3ms?

If you have an OS that provides for an interrupt (thread safe) queue 
that would also be a good solution and perhaps a bit less memory 
hungry, but not all platforms Squeak runs on give you that.

-- 
--
===========================================================================
John M. McIntosh <johnmci at smalltalkconsulting.com> 1-800-477-2659
Corporate Smalltalk Consulting Ltd.  http://www.smalltalkconsulting.com
===========================================================================