You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Each PrepareChunkMap work packet for native_ms is supposed to initialize the chunk-level metadata for a single chunk. But the code shown above clears the side mark bits for all blocks. This is totally unnecessary, and is taking up a considerable amount of time during a GC.
The problem becomes more serious when I changed the native MarkSweepSpace to use BlockPageResource instead of the raw FreeListPageResource. The reason may be that BlockPageResource caches blocks in the block queue, and releases chunks lazily, resulting in a higher number of allocated chunks during each GC.
(p.s. ReleaseMutator becomes faster because BlockPageResource::release_block is lock-free, while FreeListPageResource::release_pages needs a mutex to work, which is bad for parallel GC. See: #1145)
It should only clear the side metadata for the single chunk that the work packet is responsible for.
The text was updated successfully, but these errors were encountered:
Yeah. That code is a clear bug. I guess I simply moved the mark bit clearing code from the plan's prepare to PrepareChunkMap without realizing that PrepareChunkMap is per chunk.
wks
added a commit
to wks/mmtk-core
that referenced
this issue
Jun 11, 2024
mmtk-core/src/policy/marksweepspace/native_ms/global.rs
Lines 435 to 437 in 401803c
Each
PrepareChunkMap
work packet fornative_ms
is supposed to initialize the chunk-level metadata for a single chunk. But the code shown above clears the side mark bits for all blocks. This is totally unnecessary, and is taking up a considerable amount of time during a GC.The problem becomes more serious when I changed the native
MarkSweepSpace
to useBlockPageResource
instead of the rawFreeListPageResource
. The reason may be thatBlockPageResource
caches blocks in the block queue, and releases chunks lazily, resulting in a higher number of allocated chunks during each GC.(p.s.
ReleaseMutator
becomes faster becauseBlockPageResource::release_block
is lock-free, whileFreeListPageResource::release_pages
needs a mutex to work, which is bad for parallel GC. See: #1145)It should only clear the side metadata for the single chunk that the work packet is responsible for.
The text was updated successfully, but these errors were encountered: