Update a few comments regarding CAF lists
authorÖmer Sinan Ağacan <omeragacan@gmail.com>
Fri, 30 Mar 2018 11:58:57 +0000 (14:58 +0300)
committerÖmer Sinan Ağacan <omeragacan@gmail.com>
Fri, 30 Mar 2018 11:58:57 +0000 (14:58 +0300)
[skip ci]

includes/rts/storage/Closures.h
rts/sm/GC.c
rts/sm/Storage.c

index af89507..e5b274d 100644 (file)
@@ -122,8 +122,10 @@ typedef struct {
 typedef struct {
     StgHeader     header;
     StgClosure   *indirectee;
-    StgClosure   *static_link;
+    StgClosure   *static_link; // See Note [CAF lists]
     const StgInfoTable *saved_info;
+        // `saved_info` also used for the link field for `debug_caf_list`,
+        // see `newCAF` and Note [CAF lists]
 } StgIndStatic;
 
 typedef struct StgBlockingQueue_ {
index d7d3723..9e6bd55 100644 (file)
@@ -1831,8 +1831,8 @@ resize_nursery (void)
    Sanity code for CAF garbage collection.
 
    With DEBUG turned on, we manage a CAF list in addition to the SRT
-   mechanism.  After GC, we run down the CAF list and blackhole any
-   CAFs which have been garbage collected.  This means we get an error
+   mechanism.  After GC, we run down the CAF list and make any
+   CAFs which have been garbage collected GCD_CAF.  This means we get an error
    whenever the program tries to enter a garbage collected CAF.
 
    Any garbage collected CAFs are taken off the CAF list at the same
index c4dbdc2..9174646 100644 (file)
@@ -303,10 +303,10 @@ freeStorage (bool free_heap)
 
    The entry code for every CAF does the following:
 
-      - calls newCaf, which builds a CAF_BLACKHOLE on the heap and atomically
+      - calls newCAF, which builds a CAF_BLACKHOLE on the heap and atomically
         updates the CAF with IND_STATIC pointing to the CAF_BLACKHOLE
 
-      - if newCaf returns zero, it re-enters the CAF (see Note [atomic
+      - if newCAF returns zero, it re-enters the CAF (see Note [atomic
         CAF entry])
 
       - pushes an update frame pointing to the CAF_BLACKHOLE
@@ -317,7 +317,7 @@ freeStorage (bool free_heap)
    too, and various other parts of the RTS that deal with update
    frames would also need special cases for static update frames.
 
-   newCaf() does the following:
+   newCAF() does the following:
 
       - atomically locks the CAF (see [atomic CAF entry])
 
@@ -335,7 +335,7 @@ freeStorage (bool free_heap)
    ------------------
    Note [atomic CAF entry]
 
-   With THREADED_RTS, newCaf() is required to be atomic (see
+   With THREADED_RTS, newCAF() is required to be atomic (see
    #5558). This is because if two threads happened to enter the same
    CAF simultaneously, they would create two distinct CAF_BLACKHOLEs,
    and so the normal threadPaused() machinery for detecting duplicate
@@ -355,7 +355,7 @@ freeStorage (bool free_heap)
       - we must be able to *revert* CAFs that have been evaluated, to
         their pre-evaluated form.
 
-      To do this, we use an additional CAF list.  When newCaf() is
+      To do this, we use an additional CAF list.  When newCAF() is
       called on a dynamically-loaded CAF, we add it to the CAF list
       instead of the old-generation mutable list, and save away its
       old info pointer (in caf->saved_info) for later reversion.