In tests/runtime/test-ephemeron.scm, I wrote (define (reference-barrier object) (identity-procedure object))
before I added REFERENCE-BARRIER as an alias for IDENTITY-PROCEDURE to the system global environment. Later, I compiled test-ephemeron.scm and loaded it into a child of the system global environment, and was surprised to find that calls to the value of REFERENCE-BARRIER in that environment spun in an infinite loop. Here's what happened: When the microcode linked the code block, it filled the uuo-link for the call to IDENTITY-PROCEDURE with the right target. Also, in the cache to which IDENTITY-PROCEDURE is bound in the system global environment, the microcode recorded an entry for the uuo-link. Next, test-ephemeron.scm defined REFERENCE-BARRIER in the child environment. Not only did the microcode then create a binding for REFERENCE-BARRIER in the child environment, but it also went through the references to the cache to which REFERENCE-BARRIER is bound in the parent (system global) environment, and replaced any such references that occurred in the child environment by references to the binding for REFERENCE-BARRIER in the child environment. Unfortunately, this cache is identical to the cache to which IDENTITY-PROCEDURE is bound in the parent environment, so the microcode replaced target of the uuo-link in the REFERENCE-BARRIER procedure by the REFERENCE-BARRIER procedure itself! I think the problem is that update_cache_references and the associated routines don't take the name of the binding involved, causing them to update references that they shouldn't update, because they were to different names. But I don't know this code very well, and it is very complicated, so I thought I'd look for other opinions before I attempt to tackle this. _______________________________________________ MIT-Scheme-devel mailing list [email protected] http://lists.gnu.org/mailman/listinfo/mit-scheme-devel
