chicken-hackers
[Top][All Lists]
Advanced

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

[PATCH] Use weak chain approach for locatives, too


From: Peter Bex
Subject: [PATCH] Use weak chain approach for locatives, too
Date: Tue, 27 Jun 2023 08:42:34 +0200

Hi all,

Here's a patch to replace the locative table with the same approach we
use for weak pair tracking.  Not much to say, the idea is simple, the
patch a bit bigger (because it rips out the locative table).

There's no manual or NEWS entry because this should not be user-visible
unless code creates lots of garbage locatives (as those would not be
traversed during GC, unlike before).

As I point out in the commit message, I think it would be worthwile for
CHICKEN 6 to change the representation of locatives.  Let me elaborate:

Currently, we store a direct C pointer to the target object's slot
in the locative's first slot.  Because we also need to update said
pointer during GC, we also store the offset (in the second slot) and
do lots of calculations on *every* GC, for *every* locative, to find
the original object, chase its forwarding pointer and then re-apply
the offset.  There's a fourth slot for the type of object (which we
use to determine the offset's "stride" and when dereferencing to
figure out how to "convert" it. Finally, there's a fifth slot which
holds either the object (again!) or #f if it's a weak locative.

Graphically:

   ------------------------------------------------
  | HEADER | PTR | FX offset | FX subtype | OBJ/#f |
   ------------------------------------------------

If we change it such that we *always* store the object
in the first slot, we can make the distinction of weak/strong refs
like we do for pairs: set the C_SPECIALBLOCK_BIT conditionally
when the reference is weak, and clear it if it's strong.

Graphically:

   ---------------------------------------
  | HEADER | OBJ | FX offset | FX subtype |
   ---------------------------------------

This change has two benefits:

- locatives are smaller, so (slightly) less GC pressure if
  lots of these are made.  But more importantly:
- when traversing locatives, we *only* have to process
  weak locatives specially in the GC, and there's no need to
  recalculate the pointer.  This means if a program uses only
  strong locatives, there is *no additional penalty* incurred
  after a garbage collection run.

The only disadvantage is that every access of a locative will
now have to do the calculation to find the base pointer.  This
might slow down locative-ref somewhat.  But I think it's
manageable - we already have a switch statement in locative_ref,
so adding the offset calculation for all the different types of
locatives is trivial and should only add *very* minor overhead,
while the GCs should all be faster.

The change should be relatively minor, but because it's a change
in the representation, and there may be code out there that
relies on the current representation, I think this change is
better left for CHICKEN 6.

Cheers,
Peter

Attachment: 0001-Replace-locative-table-with-simpler-weak-chain-solut.patch
Description: Text document

Attachment: signature.asc
Description: PGP signature


reply via email to

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