Fix length of Map64::descriptor_map (#956)

Its length should be MAX_SPACES instead of MAX_CHUNKS.

The size was `MAX_SPACES` in the JikesRVM MMTk. It may have been a typo
when porting JikesRVM MMTk to Rust.

The new `Map64::descriptor_map` does not deserve the unsafe
`new_zeroed_vec` function which was introduced to solve the slow
start-up problem. We keep `new_zeroed_vec` just in case we may still
need it in the future.

Author: wks

src/util/heap/layout/map64.rs

@@ -8,7 +8,6 @@ use crate::util::heap::layout::vm_layout::*;
 use crate::util::heap::space_descriptor::SpaceDescriptor;
 use crate::util::memory::MmapStrategy;
 use crate::util::raw_memory_freelist::RawMemoryFreeList;
-use crate::util::rust_util::zeroed_alloc::new_zeroed_vec;
 use crate::util::Address;
 use std::cell::UnsafeCell;
 use std::ptr::NonNull;
@@ -49,16 +48,11 @@ impl Map64 {
             base_address[i] = base;
         }
 
+        let descriptor_map = vec![SpaceDescriptor::UNINITIALIZED; MAX_SPACES];
+
         Self {
             inner: UnsafeCell::new(Map64Inner {
-                // 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>(vm_layout().max_chunks())
-                },
+                descriptor_map,
                 high_water,
                 base_address,
                 fl_page_resources: vec![None; MAX_SPACES],

src/util/rust_util/zeroed_alloc.rs

@@ -14,6 +14,9 @@
 //! If such an allocation happens during start-up, the delay will be noticeable to light-weight
 //! scripting languages, such as Ruby.
 //!
+//! *(Note: We no longer allocate such large vecs at start-up.  We keep this module in case we need
+//! to allocate large vectors in the future.)*
+//!
 //! 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.