Commit eb7b233a authored by Ben Gamari's avatar Ben Gamari 🐢 Committed by Marge Bot

nonmoving: Fix handling on large object marking on 32-bit

Previously we would reset the pointer pointing to the object to be
marked to the beginning of the block when marking a large object. This
did no harm on 64-bit but on 32-bit it broke, e.g. `arr020`, since we
align pinned ByteArray allocations such that the payload is 8
byte-aligned. This means that the object might not begin at the
beginning of the block.,
parent 097f8072
......@@ -62,7 +62,13 @@ static void mark_PAP_payload (MarkQueue *queue,
* collector and moved to nonmoving_large_objects during the next major GC.
* When this happens the block gets its BF_NONMOVING_SWEEPING flag set to
* indicate that it is part of the snapshot and consequently should be marked by
* the nonmoving mark phase..
* the nonmoving mark phase.
*
* Note that pinned object blocks are treated as large objects containing only
* a single object. That is, the block has a single mark flag (BF_MARKED) and we
* consequently will trace the pointers of only one object per block. However,
* this is okay since the only type of pinned object supported by GHC is the
* pinned ByteArray#, which has no pointers.
*/
bdescr *nonmoving_large_objects = NULL;
......@@ -1281,9 +1287,6 @@ mark_closure (MarkQueue *queue, const StgClosure *p0, StgClosure **origin)
if (bd->flags & BF_MARKED) {
goto done;
}
// Mark contents
p = (StgClosure*)bd->start;
} else {
struct NonmovingSegment *seg = nonmovingGetSegment((StgPtr) p);
nonmoving_block_idx block_idx = nonmovingGetBlockIdx((StgPtr) p);
......
Markdown is supported
0% or
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment