Marksweep is slower in most benchmarks after #953

[qinsoon]

We see between 1% to 6% (pmd) slowndown in CI for OpenJDK after #953 (hammer-2024-05-10-Fri-144600).

[wks]

There are several possible reasons.

1. The PR Remove fl_map and refactor FreeListPageResoure #953 expanded the scope of the mutex lock in FreeListPageResource::release_pages. Now it holds the mutex lock while (1) querying the free_list.size, and (2) calling self.mprotect (LOS only).
2. The Rust compiler makes different inlining decisions after Remove fl_map and refactor FreeListPageResoure #953, making it slower.

Since the CI is not using PGO, the inlining decision is more likely to be the cause.

But the way MarkSweep sweeps block may be a bottleneck, too. MarkSweep executes SweepChunk in parallel, but whenever freeing any particular block, it needs to hold a mutex lock (even before #953).

We should look at the eBPF trace of MarkSweep to find its true inefficiency.