ZPageAllocator::cleanup_failed_commit_single_partition is responsible for cleaning up the successful part of a failed allocation by returning it to the cache so it can be reused.

When a commit fails the the parts that should be returned is any "harvested" memory (memory it took from the cache) and any partially freshly committed memory.

In a late revision of JDK-8350441 we rewrote part of the allocation logic such that the "harvested" part was no longer part of the partial vmems after successfully harvesting. However the cleanup code was not adapted to this change.

It is very rare that a commit fails, (the easiest way to provoke this behaviour is to use to few explicit huge pages for a given max heap on linux).

The way the bug manifests is that we hit an assert in a debug build, in a release build we will leak the memory that was harvested (We do not put the memory back into the cache, release it to the underlying virtual and physical allocators nor use it for a heap region). All counters are updated based on what was actually put back into the cache, so it memory will simply appear as if it is in use, but cannot be found anywhere, but not lead to a missmatch in our bookkeeping.