Android: build the collector without parallel marking - #518
Merged
Merged
Conversation
With parallel marking, several threads allocating at once deadlocked the collector during marking on an Android API 29 x86_64 emulator: the collecting thread waits in GC_do_parallel_mark for the markers, two markers block re-acquiring mark_mutex, every other thread is in the suspend handler. A plain C program reproduces it (bdwgc 8.2.12: 5 hangs in 12 runs, master: 2 in 12; GC_MARKERS=1: none), reported upstream as bdwgc/bdwgc#980. Marking now runs on the collecting thread alone. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
What
scripts/build_gc_release_android.batnow builds Boehm with-Denable_parallel_mark=OFF.Why
With parallel marking, several threads allocating at once deadlock the collector during marking on an Android API 29 x86_64 emulator:
GC_do_parallel_markfor the marker threads;mark_mutex;A plain C program reproduces it. Reported upstream as bdwgc/bdwgc#980.
GC_MARKERS=1The cost is that marking runs on the collecting thread alone.
Not solved by this
A tslang gc library whose exported function calls
array.joinover 200 fresh strings, called from 8 foreign threads, still hangs in 6 of 12 runs with this change (it hung in every run with parallel marking). The stuck state is different: the collector waits inGC_start_worldfor restart acknowledgements while every other thread has already left the suspend handler. I have not reproduced this mode in pure C yet, so it isn't attributed to Boehm. It's the next thing to investigate. Until then,-mm=rcremains the safe model for Android app libraries.Verified on the x86_64 emulator only; arm64 was rebuilt but not run.
🤖 Generated with Claude Code