Fix slow vec allocation during start-up. (#737)

Use alloc::alloc_zeroed to manually allocate the buffer for the vector of `SpaceDescriptor(usize)` to elide the storing of zeroes to its elements during start-up.

This is one of the two parts for solving the problem of slow start-up time.

Related issues:
-   #669
-   mmtk/mmtk-ruby#13

The problem is, Rust has specialised Vec creation mechanisms for built-in types, such as `usize`.  This means `vec![0usize; 33554432]` will use pre-zeroed buffers to create the Vec, and will not store `0` values to its elements.  This is very fast.  However, Rust cannot do the same optimisation for `vec![SpaceDescriptor(0); 33554432]`. It will have to store a `SpaceDescriptor(0)` to each of its 33554432 elements, and that'll be very slow.

This PR implements our own Vec creation function using `std::alloc::alloc_zeroed`.  This change alone can reduce the execution time of `MMTK::new()` from 140ms to 60ms on my machine.

Author: wks

src/util/heap/layout/map64.rs

@@ -7,6 +7,7 @@ use crate::util::heap::layout::heap_parameters::*;
 use crate::util::heap::layout::vm_layout_constants::*;
 use crate::util::heap::space_descriptor::SpaceDescriptor;
 use crate::util::raw_memory_freelist::RawMemoryFreeList;
+use crate::util::rust_util::zeroed_alloc::new_zeroed_vec;
 use crate::util::Address;
 use std::sync::atomic::{AtomicUsize, Ordering};
 
@@ -41,7 +42,12 @@ impl Map for Map64 {
         }
 
         Self {
-            descriptor_map: vec![SpaceDescriptor::UNINITIALIZED; MAX_CHUNKS],
+            // Note: descriptor_map is very large. Although it is initialized to
+            // SpaceDescriptor(0), the compiler and the standard library are not smart enough to
+            // elide the storing of 0 for each of the element.  Using standard vector creation,
+            // such as `vec![SpaceDescriptor::UNINITIALIZED; MAX_CHUNKS]`, will cause severe
+            // slowdown during start-up.
+            descriptor_map: unsafe { new_zeroed_vec::<SpaceDescriptor>(MAX_CHUNKS) },
             high_water,
             base_address,
             fl_page_resources: vec![None; MAX_SPACES],

src/util/rust_util.rs

@@ -1,3 +1,7 @@
+//! This module works around limitations of the Rust programming language, and provides missing
+//! functionalities that we may expect the Rust programming language and its standard libraries
+//! to provide.
+
 /// Const function for min value of two usize numbers.
 pub const fn min_of_usize(a: usize, b: usize) -> usize {
     if a > b {
@@ -123,3 +127,53 @@ mod initialize_once_tests {
         assert_eq!(INITIALIZE_COUNT.load(Ordering::SeqCst), 1);
     }
 }
+
+/// This module is for allocating large arrays or vectors with initial zero values.
+///
+/// Note: The standard library uses the `IsZero` trait to specialize the intialization of `Vec<T>`
+/// if the initial element values are zero.  Primitive type, such as `i8`, `usize`, `f32`, as well
+/// as types with known representations such as `Option<NonZeroUsize>` implement the `IsZero`
+/// trait.  However, it has several limitations.
+///
+/// 1.  Composite types, such as `SpaceDescriptor(usize)`, doesn't implement the `IsZero` trait,
+///     even if it has the `#[repr(transparent)]` annotation.
+/// 2.  The `IsZero` trait is private to the `std` module, and we cannot use it.
+///
+/// Therefore, `vec![0usize; 33554432]` takes only 4 **microseconds**, while
+/// `vec![SpaceDescriptor(0); 33554432]` will take 22 **milliseconds** to execute on some machine.
+/// If such an allocation happens during start-up, the delay will be noticeable to light-weight
+/// scripting languages, such as Ruby.
+///
+/// We implement our own fast allocation of large zeroed vectors in this module.  If one day Rust
+/// provides a standard way to optimize for zeroed allocation of vectors of composite types, we
+/// can switch to the standard mechanism.
+pub mod zeroed_alloc {
+
+    use std::alloc::{alloc_zeroed, Layout};
+
+    /// Allocate a `Vec<T>` of all-zero values.
+    ///
+    /// This intends to be a faster alternative to `vec![T(0), size]`.  It will allocate pre-zeroed
+    /// buffer, and not store zero values to its elements as part of initialization.
+    ///
+    /// It is useful when creating large (hundreds of megabytes) Vecs when the execution time is
+    /// critical (such as during start-up, where a 100ms delay is obvious to small applications.)
+    /// However, because of its unsafe nature, it should only be used when necessary.
+    ///
+    /// Arguments:
+    ///
+    /// -   `T`: The element type.
+    /// -   `size`: The length and capacity of the created vector.
+    ///
+    /// Returns the created vector.
+    ///
+    /// # Unsafe
+    ///
+    /// This function is unsafe.  It will not call any constructor of `T`.  The user must ensure
+    /// that a value with all bits being zero is meaningful for type `T`.
+    pub(crate) unsafe fn new_zeroed_vec<T>(size: usize) -> Vec<T> {
+        let layout = Layout::array::<T>(size).unwrap();
+        let ptr = alloc_zeroed(layout) as *mut T;
+        Vec::from_raw_parts(ptr, size, size)
+    }
+}