Yi Lin

My current conclusion is that we need a larger min heap size when we have more mutator threads when using mimalloc mark sweep. As we see the same issue with...

I didn't try with other malloc libraries. I should do that. I will get the min heap with those builds on latest dacapo.

@wks spotted an issue in https://github.com/mmtk/mmtk-core/pull/1112#discussion_r1562351335: we do not reset block state back to unmarked. In this case, once a block is marked, it stays as marked. We may sweep...

I measured the min heap for a few other plans. I have some doubts about the min heap value for mark compact with 48threads -- it keeps timing out in...

> A potential solution could be to return the allocator-local blocks to the global pool for every GC in `mutator.flush()` instead of waiting for the mutator thread to get destroyed...

Should we close this issue, or keep it open with low priority?

We need to use an address range that is allowed by ASAN for our heap. See https://github.com/mmtk/mmtk-core/issues/1088#issuecomment-2049008452. > ASAN divides the address space into a few ranges. It reserves some...

https://github.com/mmtk/mmtk-core/pull/1169 and the discussion in https://mmtk.zulipchat.com/#narrow/stream/262673-mmtk-core/topic/Nursery.20GC.20recycling.20old.20objects is another example of stale side log bits.

Can you try if it works without harness/probe?

`allow_new_candidate` is only set to `false` if we [forward refs](https://github.com/mmtk/mmtk-core/blob/53b6d57c2a96f6064e01e245ea0be05dd673cfad/src/util/reference_processor.rs#L334), which is only applicable for mark compact. Have you seen `allow_new_candidate` as `false` in Immix?