allenw@tekcrl.UUCP (Brock) (07/07/86)
Justin Graver wrote: >>We have also considered using the system tracer to modify such large classes, >>but feel that this may be an unreasonable solution. Has anyone ever used the >>tracer for such a purpose and is it feasable? Unless these problems can be > To which bob atkinson replied: >That is one of the main reasons that the SystemTracer was built in the >first place. By all means, that is a possible solution, and probably >the easiest from your point of view. I hope your tracer works: I have >yet to see one that does, though I have been told that they exist :-). >Try to make a simple clone image first and find out. > The SystemTracers provided with Tek systems most certainly works. We use them to produce our release versions of the system. A version of it was used to bootstrap our way from a small object space system (16-bit oops) to a large (32-bit oop) object space. This not only required changing the representation of oops, but also completely changed the structure of CompiledMethods and MethodDictionaries. In addition, class definitions were added/deleted/modified. We have also used it to re-assign hash values to Symbols in order to reduce the number of hash collisions in method dictionaries. Once you understand how the SystemTracer (call it cloner, for short) works it is probably the easiest way to make changes of this type. While it is often possible to get the system to change itself on the fly, there are many subtle ways of confusing the running system. Most of these can be avoided by using the cloner. In any case, any modification of the kernel classes (such as Class or CompiledMethod) requires a understanding of how the underlying implementation works. Finally, I know of at least one bug in the standard Xerox Version 2 cloner. There is a order dependency, such that if objects are encounted in some orders, there may be missing objects in the cloned image. Allen Wirfs-Brock Tektronix Inc. 503-627-6195 allenw@tektronix.UUCP (also via CS-net)