| blob | 4deae52e321903db0ef46b759b7cb12b13a3cdc3 |
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.
39 ;;; This is called in BRAID when we are making wrappers for classes
40 ;;; whose slots are not initialized yet, and which may be built-in
41 ;;; classes. We pass in the class name in addition to the class.
51 layout))
54 :length length
58 ;;; The following variable may be set to a STANDARD-CLASS that has
59 ;;; already been created by the lisp code and which is to be redefined
60 ;;; by PCL. This allows STANDARD-CLASSes to be defined and used for
61 ;;; type testing and dispatch before PCL is loaded.
64 ;;; In SBCL, as in CMU CL, the layouts (a.k.a wrappers) for built-in
65 ;;; and structure classes already exist when PCL is initialized, so we
66 ;;; don't necessarily always make a wrapper. Also, we help maintain
67 ;;; the mapping between CL:CLASS and SB-KERNEL:CLASSOID objects.
74 :length length
75 :classoid
89 found))
103 layout))))
108 ;; FIXME: this branch seems unreachable.
109 ;; It would be nice to eliminate WRAPPER-CLASS* if we can show that it
110 ;; is only a holdover from an earlier way of bootstrapping that resulted
111 ;; in the temporary absence of a PCL-CLASS for some non-standard-class.
112 ;; Certainly no test gets here [changing it to (BUG "got here") worked].
113 ;; Note however that
114 ;; (CLASSOID-PCL-CLASS (FIND-CLASSOID 'STANDARD-INSTANCE)) => NIL
115 ;; which can be resolved by just ensuring one time that it has a CLASS.
116 ;; And nothing else seems to be problematic.
120 classoid))))
122 ;;; The wrapper cache machinery provides general mechanism for
123 ;;; trapping on the next access to any instance of a given class. This
124 ;;; mechanism is used to implement the updating of instances when the
125 ;;; class is redefined (MAKE-INSTANCES-OBSOLETE). The same mechanism
126 ;;; is also used to update generic function caches when there is a
127 ;;; change to the superclasses of a class.
128 ;;;
129 ;;; Basically, a given wrapper can be valid or invalid. If it is
130 ;;; invalid, it means that any attempt to do a wrapper cache lookup
131 ;;; using the wrapper should trap. Also, methods on
132 ;;; SLOT-VALUE-USING-CLASS check the wrapper validity as well. This is
133 ;;; done by calling CHECK-WRAPPER-VALIDITY.
139 ;;; We only use this inside INVALIDATE-WRAPPER.
145 ;; First off, a previous call to INVALIDATE-WRAPPER may have
146 ;; recorded OWRAPPER as an NWRAPPER to update to. Since OWRAPPER
147 ;; is about to be invalid, it no longer makes sense to update to
148 ;; it.
149 ;;
150 ;; We go back and change the previously invalidated wrappers so
151 ;; that they will now update directly to NWRAPPER. This
152 ;; corresponds to a kind of transitivity of wrapper updates.
159 ;; FIXME: We are here inside PCL lock, but might someone be
160 ;; accessing the wrapper at the same time from outside the lock?
163 ;; FIXME: We could save a whopping cons by using (STATE . WRAPPER)
164 ;; instead
166 new-previous)
171 ;;; FIXME: This is not a good name: part of the contract here is that
172 ;;; we return the valid wrapper, which is not obvious from the name
173 ;;; (or the names of our callees.)
180 owrapper)
182 ;; Obsolete structure trap.
185 ;; FIXME: I can't help thinking that, while this does cure
186 ;; the symptoms observed from some class redefinitions,
187 ;; this isn't the place to be doing this flushing.
188 ;; Nevertheless... -- CSR, 2003-05-31
189 ;;
190 ;; CMUCL comment:
191 ;; We assume in this case, that the :INVALID is from a
192 ;; previous call to REGISTER-LAYOUT for a superclass of
193 ;; INSTANCE's class. See also the comment above
194 ;; FORCE-CACHE-FLUSHES. Paul Dietz has test cases for this.
197 ;; KLUDGE: avoid an infinite recursion, it's still better to
198 ;; bail out with an error for server softwares. see FIXME above.
199 ;; details: http://thread.gmane.org/gmane.lisp.steel-bank.devel/10175
200 ;;
201 ;; Error message here is trying to figure out a bit more about the
202 ;; situation, since we don't have anything approaching a test-case
203 ;; for the bug.
208 to sbcl-devel.~
209 ~% Owrapper: ~S~
210 ~% Wrapper-of: ~S~
211 ~% Class-wrapper: ~S~%~:@>"
220 (:flush
228 (:obsolete
240 wrapper)))
241 \f
242 ;;; NIL: means nothing so far, no actual arg info has NILs in the
243 ;;; metatype.
244 ;;;
245 ;;; CLASS: seen all sorts of metaclasses (specifically, more than one
246 ;;; of the next 5 values) or else have seen something which doesn't
247 ;;; fall into a single category (SLOT-INSTANCE, FORWARD). Also used
248 ;;; when seen a non-standard specializer.
249 ;;;
250 ;;; T: means everything so far is the class T.
251 ;;;
252 ;;; The above three are the really important ones, as they affect how
253 ;;; discriminating functions are computed. There are some other
254 ;;; possible metatypes:
255 ;;;
256 ;;; * STANDARD-INSTANCE: seen only standard classes
257 ;;; * BUILT-IN-INSTANCE: seen only built in classes
258 ;;; * STRUCTURE-INSTANCE: seen only structure classes
259 ;;; * CONDITION-INSTANCE: seen only condition classes
260 ;;;
261 ;;; but these are largely unexploited as of 2007-05-10. The
262 ;;; distinction between STANDARD-INSTANCE and the others is used in
263 ;;; emitting wrapper/slot-getting code in accessor discriminating
264 ;;; functions (see EMIT-FETCH-WRAPPER and EMIT-READER/WRITER); it is
265 ;;; possible that there was an intention to use these metatypes to
266 ;;; specialize cache implementation or discrimination nets, but this
267 ;;; has not occurred as yet.
279 x))
292 (meta-specializer ~S).~@:>"
293 new-specializer meta-specializer))))))
294 ;; We implement the following table. The notation is
295 ;; that X and Y are distinct meta specializer names.
296 ;;
297 ;; NIL <anything> ===> <anything>
298 ;; X X ===> X
299 ;; X Y ===> CLASS
311 invalid-arguments-form
348 ,invalid-arguments-form