mit-scheme-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[MIT-Scheme-devel] bug in shadowing caches


From: Taylor R Campbell
Subject: [MIT-Scheme-devel] bug in shadowing caches
Date: Fri, 20 Aug 2010 01:40:02 +0000
User-agent: IMAIL/1.21; Edwin/3.116; MIT-Scheme/9.0.1

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.



reply via email to

[Prev in Thread] Current Thread [Next in Thread]