Re: Inlined TYPEP over-optimization bug with CHANGE-CLASS

Dan Corkill <[email protected]> writes:

> Recent CMUCL releases (including the current one), incorrectly over-optimize TYPEP and
> miss the class change resulting from CHANGE-CLASS. 

> (defmethod show-bug ((instance foo))
>  (change-class instance 'bar)
>  (format t "~&;; Inlined TYPEP: ~s (incorrect)~%;; Not-inlined TYPEP: ~s (correct)~%"
>          (typep instance 'foo)
>          (locally (declare (notinline typep))
>            (typep instance 'foo))))

Changing the class of an instance within a method specializing on that
instance to a class where the method would no longer have been called is
one of the things that the CLHS description of change-class calls
"semantic difficulties".

Not speaking for CMUCL developers, I would call it a downright bad idea
to mess with the classes of specialized instances in methods -- allowing
the programmer to do invalidates whole classes of CLOS optimizations.
The CLHS specifically calls out slot access, but that's just one case of
a general problem: after you issue the change-class, the method
currently running is no longer an applicable method to the instance, so
all the compiler assumptions have just been invalidated, and all the
run-time calculations of next methods also (though they're not present
in your example).

Best,

Christophe
_______________________________________________
cmucl-help mailing list
[email protected]
http://lists.zs64.net/mailman/listinfo/cmucl-help