Changeset 14723 for trunk/source/lisp-kernel/x86-gc.c

Timestamp:

Apr 21, 2011, 9:20:04 PM (9 years ago)

Author:

gb

Message:

In mark_memoized_area() on all platforms, don't do any special
processing of weak-on-value hash vectors. (This means that otherwise
unreferenced values in weak-on-value hash tables will only be free
on a full GC.) This seems to fix (at least the symptom of) ticket:817,
or at least allows my test case to run to completion.

The real problem is that sometimes those weak-on-value hash vectors
aren't on GCweakvll; if we don't mark the values in the weak vector
in mark_memoized_area(), nothing deletes unmarked values from the
hash table (or otherwise completes weak processing.) I was unable
to determine why the vectors were sometimes missing from the list;
not dropping them in init_weakvll() didn't seem to fix anything.

One approach to fixing the real problem is to say:

• we somehow ensure that tenured weak-on-value hash vectors always have refbits set for their headers.
• on entry to the GC, GCweakvll is empty (or at least contains no hash vectors).
• mark_memoized_area does weak processing of all tenured weak hash vectors. If it finds that the vector contains intergenerational references to weak elements, it pushes the vector on GCweakvll.
• if lisp_global(WEAKVLL) and init_weakvll() need to continue to exist, that's only so that weak list headers can be preprocessed. It'd be nice to think of a way of doing that preprocessing via other means.

File:

• trunk/source/lisp-kernel/x86-gc.c (modified) (4 diffs)

trunk/source/lisp-kernel/x86-gc.c

@@ -1254 +1254 @@
      Some headers are "interesting", to the forwarder if not to us. 
 
-     */
+  */
 
   /*
@@ -1262 +1262 @@
     a time and doing a cntlzw instruction; and don't want to have to
     check for (< memo_dnode num_memo_dnodes) in the loop.
-    */
+  */
 
   {
@@ -1298 +1298 @@
       x2 = *p++;
       bits &= ~(BIT0_MASK >> bitidx);
+
 
       if (hashp) {
@@ -1330 +1331 @@
         hash_table_vector_header *hp = (hash_table_vector_header *)(p - 2);
         if (hp->flags & nhash_weak_mask) {
-          /* If header_count is odd, this cuts off the last header field */
-          /* That case is handled specially above */
-          hash_dnode_limit = memo_dnode + ((hash_table_vector_header_count) >>1);
-          hashp = hp;
-          mark_method = 3;
+          /* Work around the issue that seems to cause ticket:817,
+             which is that tenured hash vectors that are weak on value
+             aren't always maintained on GCweakvll.  If they aren't and
+             we process them weakly here, nothing will delete the unreferenced
+             elements. */
+          if (!(hp->flags & nhash_weak_value_mask)) {
+            /* If header_count is odd, this cuts off the last header field */
+            /* That case is handled specially above */
+            hash_dnode_limit = memo_dnode + ((hash_table_vector_header_count) >>1);
+            hashp = hp;
+            mark_method = 3;
+
+
+
+
+
+          }
         }
       }