| blob | c204e4f8b21b1b518db7debf000e28a46d7d2a4e |
1 ;;;; Bits and pieces of the wrapper machninery. This used to live in cache.lisp,
2 ;;;; but doesn't really logically belong there.
4 ;;;; This software is part of the SBCL system. See the README file for
5 ;;;; more information.
7 ;;;; This software is derived from software originally released by Xerox
8 ;;;; Corporation. Copyright and release statements follow. Later modifications
9 ;;;; to the software are in the public domain and are provided with
10 ;;;; absolutely no warranty. See the COPYING and CREDITS files for more
11 ;;;; information.
13 ;;;; copyright information from original PCL sources:
14 ;;;;
15 ;;;; Copyright (c) 1985, 1986, 1987, 1988, 1989, 1990 Xerox Corporation.
16 ;;;; All rights reserved.
17 ;;;;
18 ;;;; Use and copying of this software and preparation of derivative works based
19 ;;;; upon this software are permitted. Any distribution of this software or
20 ;;;; derivative works must comply with all applicable United States export
21 ;;;; control laws.
22 ;;;;
23 ;;;; This software is made available AS IS, and Xerox Corporation makes no
24 ;;;; warranty about the software, its performance or its conformity to any
25 ;;;; specification.
34 ;;; This is called in BRAID when we are making wrappers for classes
35 ;;; whose slots are not initialized yet, and which may be built-in
36 ;;; classes. We pass in the class name in addition to the class.
46 layout))
49 :length length
53 ;;; The following variable may be set to a STANDARD-CLASS that has
54 ;;; already been created by the lisp code and which is to be redefined
55 ;;; by PCL. This allows STANDARD-CLASSes to be defined and used for
56 ;;; type testing and dispatch before PCL is loaded.
59 ;;; In SBCL, as in CMU CL, the layouts (a.k.a wrappers) for built-in
60 ;;; and structure classes already exist when PCL is initialized, so we
61 ;;; don't necessarily always make a wrapper. Also, we help maintain
62 ;;; the mapping between CL:CLASS and SB-KERNEL:CLASSOID objects.
68 :length length
69 :classoid
83 found))
97 layout))))
105 ;;; The wrapper cache machinery provides general mechanism for
106 ;;; trapping on the next access to any instance of a given class. This
107 ;;; mechanism is used to implement the updating of instances when the
108 ;;; class is redefined (MAKE-INSTANCES-OBSOLETE). The same mechanism
109 ;;; is also used to update generic function caches when there is a
110 ;;; change to the superclasses of a class.
111 ;;;
112 ;;; Basically, a given wrapper can be valid or invalid. If it is
113 ;;; invalid, it means that any attempt to do a wrapper cache lookup
114 ;;; using the wrapper should trap. Also, methods on
115 ;;; SLOT-VALUE-USING-CLASS check the wrapper validity as well. This is
116 ;;; done by calling CHECK-WRAPPER-VALIDITY.
122 ;;; We only use this inside INVALIDATE-WRAPPER.
125 ;;; We always call this inside WITH-PCL-LOCK.
129 ;; First off, a previous call to INVALIDATE-WRAPPER may have
130 ;; recorded OWRAPPER as an NWRAPPER to update to. Since OWRAPPER
131 ;; is about to be invalid, it no longer makes sense to update to
132 ;; it.
133 ;;
134 ;; We go back and change the previously invalidated wrappers so
135 ;; that they will now update directly to NWRAPPER. This
136 ;; corresponds to a kind of transitivity of wrapper updates.
143 ;; FIXME: We are here inside PCL lock, but might someone be
144 ;; accessing the wrapper at the same time from outside the lock?
147 ;; FIXME: We could save a whopping cons by using (STATE . WRAPPER)
148 ;; instead
150 new-previous)
155 ;;; FIXME: This is not a good name: part of the constract here is that
156 ;;; we return the valid wrapper, which is not obvious from the name
157 ;;; (or the names of our callees.)
163 owrapper)
165 ;; Obsolete structure trap.
168 ;; FIXME: I can't help thinking that, while this does cure
169 ;; the symptoms observed from some class redefinitions,
170 ;; this isn't the place to be doing this flushing.
171 ;; Nevertheless... -- CSR, 2003-05-31
172 ;;
173 ;; CMUCL comment:
174 ;; We assume in this case, that the :INVALID is from a
175 ;; previous call to REGISTER-LAYOUT for a superclass of
176 ;; INSTANCE's class. See also the comment above
177 ;; FORCE-CACHE-FLUSHES. Paul Dietz has test cases for this.
182 (:flush
184 (:obsolete
198 wrapper)))
199 \f
200 ;;; NIL: means nothing so far, no actual arg info has NILs in the
201 ;;; metatype.
202 ;;;
203 ;;; CLASS: seen all sorts of metaclasses (specifically, more than one
204 ;;; of the next 5 values) or else have seen something which doesn't
205 ;;; fall into a single category (SLOT-INSTANCE, FORWARD). Also used
206 ;;; when seen a non-standard specializer.
207 ;;;
208 ;;; T: means everything so far is the class T.
209 ;;;
210 ;;; The above three are the really important ones, as they affect how
211 ;;; discriminating functions are computed. There are some other
212 ;;; possible metatypes:
213 ;;;
214 ;;; * STANDARD-INSTANCE: seen only standard classes
215 ;;; * BUILT-IN-INSTANCE: seen only built in classes
216 ;;; * STRUCTURE-INSTANCE: seen only structure classes
217 ;;; * CONDITION-INSTANCE: seen only condition classes
218 ;;;
219 ;;; but these are largely unexploited as of 2007-05-10. The
220 ;;; distinction between STANDARD-INSTANCE and the others is used in
221 ;;; emitting wrapper/slot-getting code in accessor discriminating
222 ;;; functions (see EMIT-FETCH-WRAPPER and EMIT-READER/WRITER); it is
223 ;;; possible that there was an intention to use these metatypes to
224 ;;; specialize cache implementation or discrimination nets, but this
225 ;;; has not occurred as yet.
237 x))
250 (meta-specializer ~S).~@:>"
251 new-specializer meta-specializer))))))
252 ;; We implement the following table. The notation is
253 ;; that X and Y are distinct meta specializer names.
254 ;;
255 ;; NIL <anything> ===> <anything>
256 ;; X X ===> X
257 ;; X Y ===> CLASS
269 invalid-arguments-form
306 ,invalid-arguments-form