recursive cache expanding bug

[Jon L White <jonl@lucid.com>]

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.