| blob | 3ea3a2c16e11df9a70afb8dd90b239d0501d8b61 |
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 classoid))))
107 ;;; The wrapper cache machinery provides general mechanism for
108 ;;; trapping on the next access to any instance of a given class. This
109 ;;; mechanism is used to implement the updating of instances when the
110 ;;; class is redefined (MAKE-INSTANCES-OBSOLETE). The same mechanism
111 ;;; is also used to update generic function caches when there is a
112 ;;; change to the superclasses of a class.
113 ;;;
114 ;;; Basically, a given wrapper can be valid or invalid. If it is
115 ;;; invalid, it means that any attempt to do a wrapper cache lookup
116 ;;; using the wrapper should trap. Also, methods on
117 ;;; SLOT-VALUE-USING-CLASS check the wrapper validity as well. This is
118 ;;; done by calling CHECK-WRAPPER-VALIDITY.
124 ;;; We only use this inside INVALIDATE-WRAPPER.
127 ;;; We always call this inside WITH-PCL-LOCK.
131 ;; First off, a previous call to INVALIDATE-WRAPPER may have
132 ;; recorded OWRAPPER as an NWRAPPER to update to. Since OWRAPPER
133 ;; is about to be invalid, it no longer makes sense to update to
134 ;; it.
135 ;;
136 ;; We go back and change the previously invalidated wrappers so
137 ;; that they will now update directly to NWRAPPER. This
138 ;; corresponds to a kind of transitivity of wrapper updates.
145 ;; FIXME: We are here inside PCL lock, but might someone be
146 ;; accessing the wrapper at the same time from outside the lock?
149 ;; FIXME: We could save a whopping cons by using (STATE . WRAPPER)
150 ;; instead
152 new-previous)
157 ;;; FIXME: This is not a good name: part of the constract here is that
158 ;;; we return the valid wrapper, which is not obvious from the name
159 ;;; (or the names of our callees.)
165 owrapper)
167 ;; Obsolete structure trap.
170 ;; FIXME: I can't help thinking that, while this does cure
171 ;; the symptoms observed from some class redefinitions,
172 ;; this isn't the place to be doing this flushing.
173 ;; Nevertheless... -- CSR, 2003-05-31
174 ;;
175 ;; CMUCL comment:
176 ;; We assume in this case, that the :INVALID is from a
177 ;; previous call to REGISTER-LAYOUT for a superclass of
178 ;; INSTANCE's class. See also the comment above
179 ;; FORCE-CACHE-FLUSHES. Paul Dietz has test cases for this.
184 (:flush
186 (:obsolete
200 wrapper)))
201 \f
202 ;;; NIL: means nothing so far, no actual arg info has NILs in the
203 ;;; metatype.
204 ;;;
205 ;;; CLASS: seen all sorts of metaclasses (specifically, more than one
206 ;;; of the next 5 values) or else have seen something which doesn't
207 ;;; fall into a single category (SLOT-INSTANCE, FORWARD). Also used
208 ;;; when seen a non-standard specializer.
209 ;;;
210 ;;; T: means everything so far is the class T.
211 ;;;
212 ;;; The above three are the really important ones, as they affect how
213 ;;; discriminating functions are computed. There are some other
214 ;;; possible metatypes:
215 ;;;
216 ;;; * STANDARD-INSTANCE: seen only standard classes
217 ;;; * BUILT-IN-INSTANCE: seen only built in classes
218 ;;; * STRUCTURE-INSTANCE: seen only structure classes
219 ;;; * CONDITION-INSTANCE: seen only condition classes
220 ;;;
221 ;;; but these are largely unexploited as of 2007-05-10. The
222 ;;; distinction between STANDARD-INSTANCE and the others is used in
223 ;;; emitting wrapper/slot-getting code in accessor discriminating
224 ;;; functions (see EMIT-FETCH-WRAPPER and EMIT-READER/WRITER); it is
225 ;;; possible that there was an intention to use these metatypes to
226 ;;; specialize cache implementation or discrimination nets, but this
227 ;;; has not occurred as yet.
239 x))
252 (meta-specializer ~S).~@:>"
253 new-specializer meta-specializer))))))
254 ;; We implement the following table. The notation is
255 ;; that X and Y are distinct meta specializer names.
256 ;;
257 ;; NIL <anything> ===> <anything>
258 ;; X X ===> X
259 ;; X Y ===> CLASS
271 invalid-arguments-form
308 ,invalid-arguments-form