diff --git a/src/policy/marksweepspace/native_ms/global.rs b/src/policy/marksweepspace/native_ms/global.rs index a83510f723..f39b051156 100644 --- a/src/policy/marksweepspace/native_ms/global.rs +++ b/src/policy/marksweepspace/native_ms/global.rs @@ -29,6 +29,7 @@ use crate::util::heap::chunk_map::*; use crate::util::linear_scan::Region; use crate::util::VMThread; use crate::vm::ObjectModel; +use crate::vm::Scanning; use std::sync::Mutex; /// The result for `MarkSweepSpace.acquire_block()`. `MarkSweepSpace` will attempt @@ -374,7 +375,7 @@ impl MarkSweepSpace { /// Mark an object. Return `true` if the object is newly marked. Return `false` if the object /// was already marked. fn attempt_mark(&self, object: ObjectReference) -> bool { - if VM::UNIQUE_OBJECT_ENQUEUING { + if VM::VMScanning::UNIQUE_OBJECT_ENQUEUING { self.attempt_mark_atomic(object) } else { self.attempt_mark_non_atomic(object) diff --git a/src/vm/mod.rs b/src/vm/mod.rs index 6c3666b35c..a0c7c717c7 100644 --- a/src/vm/mod.rs +++ b/src/vm/mod.rs @@ -79,19 +79,4 @@ where /// Note that MMTk does not attempt to do anything to align the cursor to this value, but /// it merely asserts with this constant. const ALLOC_END_ALIGNMENT: usize = 1; - - /// When set to `true`, all plans will guarantee that during each GC, each live object is - /// enqueued at most once, and therefore scanned (by either [`Scanning::scan_object`] or - /// [`Scanning::scan_object_and_trace_edges`]) at most once. - /// - /// When set to `false`, MMTk may enqueue an object multiple times due to optimizations, such as - /// using non-atomic operatios to mark objects. Consequently, an object may be scanned multiple - /// times during a GC. - /// - /// The default value is `false` because duplicated object-enqueuing is benign for most VMs, and - /// related optimizations, such as non-atomic marking, can improve GC speed. VM bindings can - /// override this if they need. For example, some VMs piggyback on object-scanning to visit - /// objects during a GC, but may have data race if multiple GC workers visit the same object at - /// the same time. Such VMs can set this constant to `true` to workaround this problem. - const UNIQUE_OBJECT_ENQUEUING: bool = false; } diff --git a/src/vm/scanning.rs b/src/vm/scanning.rs index 05b6260f32..b02feb7fe1 100644 --- a/src/vm/scanning.rs +++ b/src/vm/scanning.rs @@ -140,6 +140,21 @@ pub trait RootsWorkFactory: Clone + Send + 'static { /// VM-specific methods for scanning roots/objects. pub trait Scanning { + /// When set to `true`, all plans will guarantee that during each GC, each live object is + /// enqueued at most once, and therefore scanned (by either [`Scanning::scan_object`] or + /// [`Scanning::scan_object_and_trace_edges`]) at most once. + /// + /// When set to `false`, MMTk may enqueue an object multiple times due to optimizations, such as + /// using non-atomic operatios to mark objects. Consequently, an object may be scanned multiple + /// times during a GC. + /// + /// The default value is `false` because duplicated object-enqueuing is benign for most VMs, and + /// related optimizations, such as non-atomic marking, can improve GC speed. VM bindings can + /// override this if they need. For example, some VMs piggyback on object-scanning to visit + /// objects during a GC, but may have data race if multiple GC workers visit the same object at + /// the same time. Such VMs can set this constant to `true` to workaround this problem. + const UNIQUE_OBJECT_ENQUEUING: bool = false; + /// Return true if the given object supports slot enqueuing. /// /// - If this returns true, MMTk core will call `scan_object` on the object.