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.

> 		int (*compilerHooks[16])();
> 		int externalPrimitiveTable[4097];

Don't know about these.

> 		int methodCache[4097];

This is superseeded by the new methodcache.

In any case, this is an optimization; it does not impact corrrectness.
But, experimentation for different sizes might be fruitful.

In the new methodcache, I arbitrarly chose 2048 slots (creating 8192
actual entries, and an array of size 65537 (256kb) to hold it), believing
that no inner loop in morphic or elsewhere is going to be using more
than 1000-2000 selector/class pairs at once.

> 		int remapBuffer[26];

I know nothing about this.

> 		int rootTable[2501];

With the root-table-overflow patch, a root table overflow costs an incrgc
and a tenure operation, not a fullGC. Thus, this parameter has lost most
of its importance. (For certain workloads, experimentation may show that
this number should be reduced.)

In any case, barring pathological cases, AFAIK, this parameter does not
impact correctness.

> 		int semaphoresToSignalA[501];
> 		int semaphoresToSignalB[501];

Dunno about these. Would these be a limit on the maximum number of open
sockets?


Scott