[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Compilation of methods per class.
- To: email@example.com
- Subject: Compilation of methods per class.
- From: Jon L White <jonl@lucid.COM>
- Date: Wed, 26 Sep 1990 18:58:01 PDT
- Cc: firstname.lastname@example.org
- In-reply-to: "email@example.com's message of Wed, 26 Sep 90 17:22:54 PDT <9009270022.AA00308@miles>"
re: Are you saying that the Victoria Day cache lookup code can get repeated
misses (calls to DCODE-CACHE-MISS) even though the entry is, or should
be, in the cache? If so, this is exactly the bug that Gregor referred to.
A fix is appended to this message.
Your comments seems to equate "cache miss" with calling DCODE-CACHE-MISS.
Despite the tempting analogy of the function's name, this is not the case,
for DCODE-CACHE-MISS serves a triple purpose:
(1) cache replacement step on a true miss
(2) search of alternate cache "lines" when the entry is in the cache,
but isn't present in the first "line" (or, perhaps second line too).
(3) cache refilling, from old contents, when it is expanded to a new size.
I think the bug fix you mention might be relevant to the glitch where
caches were being needlesly expanded, rather than undergoing the usual
"cache replacement" algorithm. As such, it is a performace loss, but is
not in any substantial way relevant to the "breakdown in assumptions".
That breakdown, as I previously mentioned, turns on the total percentage
of lookups that result in out-of-line calls (sum of 1 and 2 above), and
would still be apparent after loading in the patch. [Trent: can you
clarify whether or not you have installed the patch?]
If, as you said previously, someone switched the PCL technique in the
May 1990 version *** so that it doesn't use classical caching
techniques (in particular, so that it forgoes "cache replacement" on
true miss) *** then they must have understood the "breakdown" issue.
Contact me privately if this is still unclear.
-- JonL --