High GC overhead in JIT workload

Summary

Hi Codon maintainers,

We noticed a performance degradation in a JIT/Python interop workload that appears to be correlated with native GC marking. Codon currently uses the Boehm GC, which is a conservative GC that identifies unreachable objects by tracing pointer chains. Since it cannot precisely distinguish object pointers from pointer-like values, GC collection can become expensive in JIT scenarios where many thread stack frames need to be scanned and marked during GC_collect_or_expand.

Attached traces

I am attaching two Chrome trace JSON files:

• codon_gc_regression_case_1.trace.json
• codon_gc_regression_case_2.trace.json

They can be opened with Chrome's trace viewer / Perfetto UI.

Question

• Is this level of GC marking overhead expected for JIT workloads under the current Boehm GC integration?
• Are there recommended ways to reduce this overhead, especially for workloads that create many temporary Codon/Python interop objects or views?

I can try to provide a smaller reproducer if that would be helpful. For now, the attached traces preserve the relevant runtime behavior while removing application-specific details.

Thanks!