[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
recursive cache expanding bug
- To: Gregor.pa@Xerox.COM
- Subject: recursive cache expanding bug
- From: Jon L White <email@example.com>
- Date: Wed, 5 Jul 89 21:40:09 PDT
- Cc: kanderso@DINO.BBN.COM, commonloops.pa@Xerox.COM, Jmorrill@DINO.BBN.COM, firstname.lastname@example.org
- In-reply-to: Gregor.pa@Xerox.COM's message of Sat, 24 Jun 89 16:21 PDT <19890624232110.7.GREGOR@SPIFF.parc.xerox.com>
- Redistributed: commonloops.pa
re: [Ken]: I installed this change.
2. Suppose something calls CLASS-DIRECT-SUBCLASSES,
EXPAND-DCODE-CACHE is called to expand the cache of
CLASS-DIRECT-SUBCLASSES and either GENERIC-FUNCTION-CACHE or
SLOT-VALUE-USING-CLASS are invalidated. Then the innocent looking
line (Is this really another cache locking issue?)
[Gregor]: Sort of, it also resembles the metacircularity issues of
having to call a generic function as part of updating that same
generic function. . . .
I think it really is the metacircularity issue. Isn't that the main
reason you have the parallel slot-reader interfaces SLOT-VALUE--FSC and
SLOT-VALUE--STD? Alternatively, the line:
(setf (generic-function-cache generic-function) new-cache)
could easily have been written:
(setf (slot-value generic-function 'cache) new-cache)
and the circular dependency would have been avoided. In this particular,
case the slow-down implied by going through SLOT-VALUE-ABUSING-CLASS
(rather than through some sort of setf on SLOT-VALUE--FSC) could hardly
be noticeable, given all that cache-expansion entails.
One amusing consequence of the use of *INVALID-GENERIC-FUNCTIONS-ON-STACK*
in NOTICE-METHODS-CHANGE-2 is that it masks a whole slew of metacircular
references. Apparently it's main purpose was to prevent the clobberage
of a function which has called out to another but which will eventually
be returned to after the update; here is the comment from methods.lisp:
;; Note that because this closure will be the discriminator code
;; of a generic function it must be careful about how it changes
;; the discriminator code of that same generic function. If it
;; isn't careful, it could change its closure variables out from
;; under itself.
But with the use of "mattress pad" discriminators, rather than of
functions that are actually clobbered, there is no longer a need for
keeping track of *<anything>-ON-STACK*. At least not for the purposes
of preventing clobberage of running code.
-- JonL --
P.S.: Looks like the Victoria Day PCL hasn't put the equivalent of
'cache-lock-count' into the cache used by SLOT-VALUE--STD and
SLOT-VALUE--FSC; so they still have the prospect of being slowed
down by WITHOUT-INTERRUPTS as Ken noted some months ago.