Dead `embedded_meta_data`

[wks]

The crate::util::alloc::embedded_meta_data module is only used in the following places:

• in an unused method MonotonicPageResource::get_region_start
• in FreeListPageResource::update_discontiguous_start where it uses BYTES_IN_REGION as if it is the chunk size.
• in FreeListPageResource::alloc_pages which uses PAGES_IN_REGION as if it were chunk size, too.
• in FreeListPageResource::new_contiguous which sets the "grain" size of the freelist to PAGES_IN_REGION. It should be pages in chunk because we know the free list from a VMMap has chunk granularity.
• in the constants::card_scanning module where it defines several constants based on LOG_BYTES_IN_REGION.

It looks as if the concept "region" here is used as a synonym of "chunk". The doc comments and git blame date show that those code may be related to some legacy features from JikesRVM. We need to do more code archaeology to find its true purpose. If we think the "region" in embedded_meta_data is just a synonym of chunk, we can remove it.

[wks]

EmbeddedMetaData was introduced back in JikesRVM by @steveblackburn in https://github.com/JikesRVM/JikesRVM/commit/9310277c in 2004. The idea was embedding metadata at the beginning of each "region", and the size of "region" should be big enough to avoid the L1 cache problem, as we discussed previously in https://github.com/mmtk/mmtk-core/issues/1347.

Back in https://github.com/JikesRVM/JikesRVM/commit/9310277c, the universal concept of 4MB "Chunk" didn't exist. There were "mmap chunk" which was 1MB by then, and 4MB now in mmtk-core (but I plan to remove it in https://github.com/mmtk/mmtk-core/pull/1369), and bump pointer chunk which was 8 pages (32K) by then, and renamed to "block" (also 32K) now. The "region" for EmbeddedMetaData was 4MB, which was 4 "mmap chunks" by then.

But as JikesRVM evolved, the size of mmap chunks changed to 4MB, and we started to use the term "chunk" as the "Coarsest unit of address space allocation", which is also the unit of mmap, and also the unit of SFT dispatching. Knowing the disadvantage of embedded metadata (L1 cache problem), we also moved away from it in Rust MMTk. We ported the embedded_meta_data module from JikesRVM anyway in the initial porting stage of the project, but it becomes dead code now.

We may remove the embedded_meta_data module because it is unused and we are unlikely to use it again. But when eliminating existing use cases, we need to understand the intention why they use the constants in embedded_meta_data. Some code may still be assuming the presence of embedded metadata.