| blob | 1e083d93ed9ef6df3a40f5d771ceb350cbe2193f |
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 ;;; In SBCL, as in CMU CL, the layouts (a.k.a wrappers) for built-in
59 ;;; and structure classes already exist when PCL is initialized, so we
60 ;;; don't necessarily always make a wrapper. Also, we help maintain
61 ;;; the mapping between CL:CLASS and SB-KERNEL:CLASSOID objects.
68 :length length
69 :classoid
88 layout))))
93 ;; FIXME: this branch seems unreachable.
94 ;; It would be nice to eliminate WRAPPER-CLASS* if we can show that it
95 ;; is only a holdover from an earlier way of bootstrapping that resulted
96 ;; in the temporary absence of a PCL-CLASS for some non-standard-class.
97 ;; Certainly no test gets here [changing it to (BUG "got here") worked].
98 ;; Note however that
99 ;; (CLASSOID-PCL-CLASS (FIND-CLASSOID 'STANDARD-INSTANCE)) => NIL
100 ;; which can be resolved by just ensuring one time that it has a CLASS.
101 ;; And nothing else seems to be problematic.
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.
130 ;; First off, a previous call to INVALIDATE-WRAPPER may have
131 ;; recorded OWRAPPER as an NWRAPPER to update to. Since OWRAPPER
132 ;; is about to be invalid, it no longer makes sense to update to
133 ;; it.
134 ;;
135 ;; We go back and change the previously invalidated wrappers so
136 ;; that they will now update directly to NWRAPPER. This
137 ;; corresponds to a kind of transitivity of wrapper updates.
144 ;; FIXME: We are here inside PCL lock, but might someone be
145 ;; accessing the wrapper at the same time from outside the lock?
148 ;; FIXME: We could save a whopping cons by using (STATE . WRAPPER)
149 ;; instead
151 new-previous)
156 ;;; FIXME: This is not a good name: part of the contract here is that
157 ;;; we return the valid wrapper, which is not obvious from the name
158 ;;; (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.
182 ;; KLUDGE: avoid an infinite recursion, it's still better to
183 ;; bail out with an error for server softwares. see FIXME above.
184 ;; details: http://thread.gmane.org/gmane.lisp.steel-bank.devel/10175
185 ;;
186 ;; Error message here is trying to figure out a bit more about the
187 ;; situation, since we don't have anything approaching a test-case
188 ;; for the bug.
193 to sbcl-devel.~
194 ~% Owrapper: ~S~
195 ~% Wrapper-of: ~S~
196 ~% Class-wrapper: ~S~%~:@>"
205 (:flush
213 (:obsolete
225 wrapper)))
226 \f
227 ;;; NIL: means nothing so far, no actual arg info has NILs in the
228 ;;; metatype.
229 ;;;
230 ;;; CLASS: seen all sorts of metaclasses (specifically, more than one
231 ;;; of the next 5 values) or else have seen something which doesn't
232 ;;; fall into a single category (SLOT-INSTANCE, FORWARD). Also used
233 ;;; when seen a non-standard specializer.
234 ;;;
235 ;;; T: means everything so far is the class T.
236 ;;;
237 ;;; The above three are the really important ones, as they affect how
238 ;;; discriminating functions are computed. There are some other
239 ;;; possible metatypes:
240 ;;;
241 ;;; * STANDARD-INSTANCE: seen only standard classes
242 ;;; * BUILT-IN-INSTANCE: seen only built in classes
243 ;;; * STRUCTURE-INSTANCE: seen only structure classes
244 ;;; * CONDITION-INSTANCE: seen only condition classes
245 ;;;
246 ;;; but these are largely unexploited as of 2007-05-10. The
247 ;;; distinction between STANDARD-INSTANCE and the others is used in
248 ;;; emitting wrapper/slot-getting code in accessor discriminating
249 ;;; functions (see EMIT-FETCH-WRAPPER and EMIT-READER/WRITER); it is
250 ;;; possible that there was an intention to use these metatypes to
251 ;;; specialize cache implementation or discrimination nets, but this
252 ;;; has not occurred as yet.
264 x))
277 (meta-specializer ~S).~@:>"
278 new-specializer meta-specializer))))))
279 ;; We implement the following table. The notation is
280 ;; that X and Y are distinct meta specializer names.
281 ;;
282 ;; NIL <anything> ===> <anything>
283 ;; X X ===> X
284 ;; X Y ===> CLASS
296 invalid-arguments-form
333 ,invalid-arguments-form