search

mmtk / mmtk-core

Memory Management ToolKit
https://www.mmtk.io
Other
375 stars 69 forks source link

Marksweep is slower in most benchmarks after #953 #1135

Open qinsoon opened 5 months ago

qinsoon commented 5 months ago

We see between 1% to 6% (pmd) slowndown in CI for OpenJDK after https://github.com/mmtk/mmtk-core/pull/953 (hammer-2024-05-10-Fri-144600).

wks commented 5 months ago

There are several possible reasons.

  1. The PR https://github.com/mmtk/mmtk-core/pull/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 https://github.com/mmtk/mmtk-core/pull/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 https://github.com/mmtk/mmtk-core/pull/953).

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