Hi Scott, Hi John, Hi Dan,
Sorry, I couldn't get back to you all sooner. I have been a bit busy putting a final touch on my 'double clickable FreeCell.st'. More details in another message, though.
Thanks for your enlightments. At John's suggestion and to give Scott a toy to play in his optimisation effort, I made it configurable from the initialisation file 'SqM.ini' the following parameters:
(lines with ';;' at the front are commented out).
[TuningParams] ;; Was 4097 Now Default: 8192 ;; _EXTERNAL_PRIMITIVE_TABLE_SIZE_ = 16384
;; Was 501 Now Default: 1024 ;; _SEMAPHORES_TO_SIGNAL_SIZE_ = 512
;; Was 4097 Now Default: 8192 _METHOD_CACHE_SIZE_ = 16384
;; Was 65 Now Default: 128 ;; _AT_CACHE_SIZE_ = 35
;; Was 26 Now Default: 64 ;; _REMAP_BUFFER_SIZE_ = 16
;; Was 2501 Now Default: 4096 ;; _ROOT_TABLE_SIZE_ = 4096
It was found that the VM will crash at different places as _AT_CACHE_SIZE_ is reduced.
Higher _METHOD_CACHE_SIZE_ and lower _AT_CACHE_SIZE_ tend to crash the VM.
This doesn't seem to enforce Dan's statement:
int atCache[65];
Well, I just thought about what it was doing and guessed at what it
would take.
You could try doubling it and halving it. I think it will provide most
of its
benefit with only one entry.
Did I misunderstand this statement ?
I will leave it as an exercise for those who will take a trip in the SqueakMobile to implement some primitives to modify these parameters to 'change the flat tires and clean the spark plugs' while zooming back to the future. ;-)
Cheers,
PhiHo.
-----Original Message----- From: Scott A Crosby [mailto:crosby@qwes.math.cmu.edu] Sent: Thursday, March 28, 2002 10:36 PM To: PhiHo Hoang Cc: Squeak List Subject: Fixed limits in the image. (was Re: ...)
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