[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Avoid method cache locking
- To: CommonLoops.pa@Xerox.COM
- Subject: Avoid method cache locking
- From: kanderso@DINO.BBN.COM
- Date: Fri, 31 Mar 89 12:19:20 -0500
- Cc: kanderson@DINO.BBN.COM, aboulanger@DINO.BBN.COM
- Redistributed: CommonLoops.pa
I'd like to propose the PCL not lock its method caches.
When you call a generic function, it must find the effective method to
run. Effective methods are stored in a cache indexed by the class
wrappers of the specialized arguments. When the lookup is done, the
cache is locked so that only 1 process can access the cache at the
same time. This is because PCL rearranges the cache to make sure that
the looked up effective-method will be found easily next time.
I'd like to argue that locking the cache (and thus reorganizing it) is
the wrong thing to do in a LISP with multiple processes. On the
Symbolics machine, we have gotten the discrimination code down to a
minimum of 37 instructions. It turns out that 25% of this time is
spent in the 3 instructions that make up WITHOUT-INTERRUPTS. Thus
avoiding locking would speed up PCL by 25%.
On a parallel machine, like the BBN Butterfly, locking mega loozer
because if multiple processes are running the same method, they would
all have to line up and take turns.
So, i'd like to propose that the current caching mechanism be replaced
with one that builds the complete cache and never changes it unless a
method is redefined. This may make the caches bigger, (but each
implementation could trade time for space as it saw fit) but it would
produce faster descriminators, and perhaps smaller descriminators as well.