Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!tut.cis.ohio-state.edu!ucbvax!JOHN-JAMESON.DOCS.UU.SE!Victor
From: Victor@JOHN-JAMESON.DOCS.UU.SE (Bjorn Victor)
Newsgroups: comp.sys.ti.explorer
Subject: re: defstruct copy (SPR number 11035)
Message-ID: <2847186196-9592383@George-Ballantine.DoCS.UU.SE>
Date: 23 Mar 90 13:03:16 GMT
Sender: daemon@ucbvax.BERKELEY.EDU
Distribution: inet
Organization: The Internet
Lines: 32

Some debugging hours later:

As you might have seen when reading my bug report, I get the error in
GETHASH, when it tries to lock the generic-function method hash table of
#'COPY.  The lock is read-only.

This problem is not unique to DEFSTRUCTs, but to any type other than
FIXNUM, SYMBOL, CHARACTER and CONS, i.e. the types that have an
entry in the method hash table in the vanilla band.

As Clint said, the problem does not exist in a vanilla band.  In a
vanilla band, the generic-function method hash table of #'COPY is in
WORKING-STORAGE-AREA.

The problem is that the generic-function method hash table of #'COPY
somehow gets copied/transferred into the MACRO-COMPILED-PROGRAM area,
which as all lispm hackers know, is read-only.  I still don't know who
does it, but someone does.  I do a full GC with max-gen 3 before saving,
but it would seem to be a grand bug if the GC moved things between
areas.  HASH-TABLE-REHASH does the Right Thing, constructing the new
hash table in the same area as the old one.

I've found a work-around: After cold-boot, I redo the DEFGENERIC form
for COPY (which seems to give me an "invalid" hash table in the FEF),
and do (COPY T) to have it automagically reconstructed.  This first call
to COPY has to be done with SYS:%INHIBIT-READ-ONLY bound to T.

Yeach.  Give me an update to System Software Design Notes, please TI.

--Bjorn Victor		       Victor@John-Jameson.DoCS.UU.SE
Dept. of Computer Systems       or
Uppsala University, SWEDEN     Victor%John-Jameson.DoCS.UU.SE@uunet.UU.NET