This is based on a perf test with 100% survival in a container, before
and after dotnet/coreclr#22180. GC pause times were greater after that commit.
Debugging showed that the reason was that after, we were always doing
compacting GC, and objects were staying in generation 1 and not making it
to generation 2. The reason was that in the "after" build,
`should_compact_loh()` was always returning true if heap_hard_limit was
set; currently if we do an LOH compaction, we compact all other
generations too. As the comment indicates, we should decide that
automatically, not just set it to true all the time.
Commit migrated from https://github.com/dotnet/coreclr/commit/
cc14e6cecf6984c991fe906c9fe4b327b4f93f96
promotion = FALSE;//TRUE;
compaction = TRUE;
#ifdef FEATURE_LOH_COMPACTION
- loh_compaction = gc_heap::should_compact_loh();
+ loh_compaction = gc_heap::loh_compaction_requested();
#else
loh_compaction = FALSE;
#endif //FEATURE_LOH_COMPACTION
}
}
-BOOL gc_heap::should_compact_loh()
+BOOL gc_heap::loh_compaction_requested()
{
// If hard limit is specified GC will automatically decide if LOH needs to be compacted.
- return (heap_hard_limit || loh_compaction_always_p || (loh_compaction_mode != loh_compaction_default));
+ return (loh_compaction_always_p || (loh_compaction_mode != loh_compaction_default));
}
inline
void gc_heap::compact_loh()
{
- assert (should_compact_loh());
+ assert (loh_compaction_requested() || heap_hard_limit);
generation* gen = large_object_generation;
heap_segment* start_seg = heap_segment_rw (generation_start_segment (gen));
BOOL loh_object_p (uint8_t* o);
PER_HEAP_ISOLATED
- BOOL should_compact_loh();
+ BOOL loh_compaction_requested();
// If the LOH compaction mode is just to compact once,
// we need to see if we should reset it back to not compact.