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