Actionable comments posted: 2

In @crates/vm/src/object/core.rs:
- Around line 102-125: The set_gc_finalized() implementation does a non-atomic
read-modify-write using load + store on self.0.gc_bits which can lose concurrent
updates; replace that logic with an atomic fetch_or using
self.0.gc_bits.fetch_or(GcBits::FINALIZED.bits(), Relaxed) to set the finalized
bit safely. Also, if GcBits is not part of the VM public API, reduce its
visibility from pub to pub(crate) to limit its scope.
- Around line 811-829: The current set_gc_finalized implementation does a
non-atomic load then store and can clobber concurrent GC bit updates; replace
the load+store sequence in set_gc_finalized with an atomic read-modify-write
using gc_bits.fetch_or(..., Ordering::Relaxed) to set GcBits::FINALIZED without
losing other bits (use the same Ordering::Relaxed used in gc_finalized),
referencing the GcBits bitmask and the gc_bits field on the same struct so the
operation atomically ORs the FINALIZED bit in place.

Configuration used: Path: .coderabbit.yml

Review profile: CHILL

Plan: Pro

Reviewing files that changed from the base of the PR and between 8c15799 and daec095.

• crates/vm/src/object/core.rs

📄 CodeRabbit inference engine (.github/copilot-instructions.md)

**/*.rs: Follow the default rustfmt code style by running cargo fmt to format Rust code
Always run clippy to lint code (cargo clippy) before completing tasks and fix any warnings or lints introduced by changes
Follow Rust best practices for error handling and memory management
Use the macro system (pyclass, pymodule, pyfunction, etc.) when implementing Python functionality in Rust

Files:

• crates/vm/src/object/core.rs

crates/vm/src/object/core.rs (4)

472-488: gc_bits initialization to 0 is correct and keeps construction straightforward.
No concerns with this initialization site (assuming other PyInner constructors/initializers are updated similarly, which init_type_hierarchy is).

---

859-868: Finalized-guarded __del__ call is a good CPython-aligned safety net; make it rely on atomic RMW.
The control-flow looks right (mark finalized before calling __del__ to prevent reentrancy/double-finalize), but it depends on set_gc_finalized() being an atomic OR (see prior comment).

---

1324-1347: Type bootstrap: gc_bits included in partially_init! is correct.
This keeps the “all fields explicit” invariant for the unsafe bootstrap; good catch updating both type_type_ptr and object_type_ptr initializers.

---

131-145: No layout validation issues found. The gc_bits field addition is safe because:

• PyInner<T> has #[repr(C)], ensuring stable and well-defined memory layout
• All offset and size calculations use compile-time macros (offset_of!, size_of!) that automatically adjust to struct changes; no hard-coded offsets exist
• SIZEOF_PYOBJECT_HEAD is computed via size_of::<PyInner<()>>(), which correctly includes the new field
• gc_bits access patterns use proper atomic operations (load(Relaxed)), safe for concurrent access

The concern about implicit offset/layout assumptions is not applicable here.