8264223: CodeHeap::verify fails extra_hops assertion in fastdebug test #3212
When test with -XX:+VerifyCodeCache, many tests fail due to extra_hops assertion in CodeHeap::verify. See full dump in JBS.
Internal Error (src/hotspot/share/memory/heap.cpp:838), pid=1525697, tid=1525715
assert((count == 0) || (extra_hops < (16 + 2*count))) failed: CodeHeap: many extra hops due to optimization. blocks: 234, extra hops: 484.
Discussion in https://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/2019-October/035508.html doesn't tell where assertion (extra_hops < (16 + 2*count) comes from.
In CodeHeap::mark_segmap_as_used wehn is_FreeBlock_join is true, it creates extra hops in _segmap. _fragmentation_count in inced and trigger defrag_segmap when reach threshold. In my understanding, extra hop can not guarantee under (16 + 2*count).
In following extreme case, before HeapBlock free, segmap is all 0 (each blob use 1 smallest segment), suppose free action is applied from right to left. This increase 9 unnecessary hop for 1 continous HeapBlock. assertion (extra_hops < (16 + 2*count) is not safe.
Proposed fix is assert extra hops not exceed _fragmentation_count. And if it exceeds (16 + 2 * count), give warning on two many extra hops.
fastdebug tier1, tier2 with VerifyCodeCache passed on X86_64 linux, no extra assertion found.
@huishi-hs This change now passes all automated pre-integration checks.
After integration, the commit message for the final commit will be:
At the time when this comment was updated there had been 104 new commits pushed to the
As there are no conflicts, your changes will automatically be rebased on top of these commits when integrating. If you prefer to avoid this automatic rebasing, please check the documentation for the /integrate command for further details.
As you do not have Committer status in this project an existing Committer must agree to sponsor your change. Possible candidates are the reviewers of this PR (@RealLucy, @shipilev) but any other Committer may sponsor as well.
@shipilev Short answer: yes.
Once _fragmentation_count hits the limit, defragmentation is triggered (defrag_segmap(true)) and the counter is set to zero. After defragmentation, segmap should not contain any extra hops - that's the purpose of defragmentation. If is does, I would classify that as a bug.
Your commit was automatically rebased without conflicts.
Pushed as commit 011f6d1.