Move constant to Scanning

Author: wks

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<VM: VMBinding> MarkSweepSpace<VM> {
     /// 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)

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;
 }

src/vm/scanning.rs

@@ -140,6 +140,21 @@ pub trait RootsWorkFactory<SL: Slot>: Clone + Send + 'static {
 
 /// VM-specific methods for scanning roots/objects.
 pub trait Scanning<VM: VMBinding> {
+    /// 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.