test/go: TestRuntimeSetFinalizerTinyObjects is flaky

[MeteorsLiu]

Summary

TestRuntimeSetFinalizerTinyObjects can fail intermittently in LLGo CI when too few finalizers run before its deadline.

Observed failure

The failure occurred in PR #2272, whose changes are limited to the GOROOT test runner and its tests.

Failed job: https://github.com/xgo-dev/llgo/actions/runs/30794803798/job/91625841291

Environment:

• Ubuntu latest
• LLVM 19
• Go 1.24.2
• LLGo test shard 0

--- FAIL: TestRuntimeSetFinalizerTinyObjects (3.00s)
    finalizer_test.go:61: only 12/32 finalizers ran
FAIL github.com/goplus/llgo/test/go

The test creates 32 *int32 objects with finalizers and requires more than half of the finalizers to run within three seconds while repeatedly calling runtime.GC().

Other LLGo jobs in the same workflow completed successfully, including the Go 1.24.2 Ubuntu shard 1 job and both Go 1.26.5 Ubuntu shards.

Reproduction status

A focused local stress run at the PR head on Darwin/arm64 with Go 1.24.0 completed 50 iterations successfully:

llgo test -run "^TestRuntimeSetFinalizerTinyObjects$" -count=50 -timeout=10m ./test/go
PASS

There is currently no deterministic reproducer; the failure appears timing- or environment-dependent.

[cpunion]

Additional occurrence from PR #2254:

• Failed job: https://github.com/xgo-dev/llgo/actions/runs/30903553973/job/91973246522
• Environment: Ubuntu latest, LLVM 19, Go 1.24.2, LLGo test shard 0
• Failure: TestRuntimeSetFinalizerTinyObjects reached the 3-second deadline with only 0/32 finalizers ran.
• The failed job was rerun without code changes and passed: https://github.com/xgo-dev/llgo/actions/runs/30903553973/job/91988026621 (12m47s).
• The same workflow’s Go 1.26 Linux shards and the current-main Go 1.24 Linux job passed.

This second CI occurrence, with a different completion count and a successful unchanged rerun, strengthens the timing/environment-dependent diagnosis. A fix should investigate deterministic GC/finalizer synchronization before merely extending the deadline.

[cpunion]

Diagnosis and proposed fix: #2283.

runtime.GC called GC_gcollect and then LLGo runFinalizers, but did not call BDWGC GC_invoke_finalizers to transfer ready callbacks into the Go queue. BDWGC may otherwise invoke them only during later allocations, which explains the timing-dependent completion counts.

A deterministic LLGo-only regression enables BDWGC finalize_on_demand: before the fix, eight explicit GC calls run 0/32 finalizers; after explicitly draining the BDWGC queue, it passes. The original finalizer/cancel/on-demand selection passed 200 repetitions, with complete test/go, weak-pointer, and memprofile validation also passing.