Don't compact LOH just because a heap_hard_limit exists
authorAndy Hanson <anhans@microsoft.com>
Tue, 5 Mar 2019 22:29:31 +0000 (14:29 -0800)
committerAndy Hanson <anhans@microsoft.com>
Wed, 20 Mar 2019 19:14:08 +0000 (12:14 -0700)
commitcc14e6cecf6984c991fe906c9fe4b327b4f93f96
tree90d6bf4b8ac794555f72a53e5d8a4bda19fecddf
parented52a006c01a582d4d34add40c318d6f324b99ba
Don't compact LOH just because a heap_hard_limit exists

This is based on a perf test with 100% survival in a container, before
and after #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.
src/gc/gc.cpp
src/gc/gcpriv.h