Enable Boehm parallel marking (PARALLEL_MARK)

[dg1sbg]

PARALLEL_MARK was left undefined in boehm_config.h — the config-header template default — even though bdwgc's own CMake build defaults it ON and GC_THREADS / THREAD_LOCAL_ALLOC are already enabled here. Marking therefore ran single-threaded, and GC_mark_from is the dominant runtime cost (~25–30% in profiles) on multicore machines.

One line of actual change.

Why parallel markers are safe here

Parallel marking is only safe if the marking loop being parallelised is bdwgc's own. Clasp contributes no marking logic of its own:

• Marking is Boehm-standard conservative marking — ALL_INTERIOR_POINTERS is 1 (boehm_config.h:5) and GC_register_displacement is called for GENERAL_TAG and CONS_TAG (boehmGarbageCollection.cc:210,218-219).
• There are no custom mark procedures and no typed descriptors anywhere in the tree: GC_new_kind, GC_new_proc, GC_MAKE_PROC, GC_DS_PROC and GC_make_descriptor have zero occurrences outside src/bdwgc/.
• Every allocation kind is one of the two builtins. gc_boot.cc:395-400 sets global_lisp_kind, global_cons_kind, global_class_kind, global_container_kind and global_code_kind to GC_I_NORMAL, and global_atomic_kind to GC_I_PTRFREE.
• That holds on the precise path too — those assignments sit inside the walk == precise_info branch, where the per-stamp layout bitmaps are computed and validated (including the Cons_O bitmap assertion) but never become GC mark descriptors.

That the define reaches the collector

Worth stating explicitly, because boehm_config.h is included by only one Clasp source file and build.ninja contains no bdwgc compile rules — which makes it look inert. It isn't: src/gctools/mygc.c is the single translation unit Clasp builds bdwgc from, and it does

#include "clasp/gctools/boehm_config.h"
#include "extra/gc.c"

Confirmed empirically both ways after the change: GC_start_mark_threads becomes a defined symbol in libclasp (it is absent before), and with GC_PRINT_STATS=1 bdwgc reports Started 9 mark helper threads.

Measured effect

Marking cost on a ~1 GB live heap, median of 12 full collections. Both sides are the same binary — GC_MARKERS=1 disables parallel marking at runtime — so there is no rebuild and no second variable:

	run 1	run 2	run 3
GC_MARKERS=1 (serial)	0.0702 s	0.0665 s	0.0662 s
default (parallel)	0.0187 s	0.0205 s	0.0187 s

Roughly 3.4–3.75× faster marking, with non-overlapping ranges across all three runs.

Testing

macOS arm64, :extensions (). Full regression suite and ansi-test across both GC variants and both build modes — the :bytecode rows are a real :build-mode :bytecode build (koga re-run, modules compiled :native nil, --base resolving to base.fasl), not merely a different image booted:

build-mode	GC variant	regression	ansi-test
:native	boehmprecise	1979 successes, 4 failures	27 failures, 0 unexpected
:native	boehm	1977 successes, 4 failures	—
:bytecode	boehmprecise	1979 successes, 4 failures	27 failures, 0 unexpected
:bytecode	boehm	1977 successes, 4 failures	27 failures, 0 unexpected

Every failure set is the same four entries already in *expected-failures* (SBCL-CROSS-COMPILE-4, INCLUDE-LEVEL-2B, INCLUDE-LEVEL-3, TYPES-CLASSES-10), and the boehmprecise/:native run is test-by-test identical to the unmodified build. The bytecode image was additionally exercised under both GC variants from the :native build via --image, with the same results.

Concurrent-GC correctness stress: 8 threads churning 849 MB of mixed conses, strings and vectors while repeatedly walking a shared live tree and verifying its checksum — 400 full verifications during concurrent allocation, checksum intact throughout, all worker results exact.

One caveat for CI: PRINT.DOUBLE-FLOAT.RANDOM is flaky for reasons unrelated to this PR (see #1816) and can redden ansi-test at random, so its exit code alone is not a verdict — compare the failure lists.