While investigating JDK-8366147 we also found that ZPageAllocator::cleanup_failed_commit_multi_partition is broken.

The implementation is intended to work by going over each partitions part of the allocation one by one and returning any harvested or committed and mapped memory to to cache and returning any failed to be committed physical associations back to our internal free lists.

But when deriving what part of the memory is associated with which partition it uses the wrong variable and ends up working with the wrong memory. And multiple partitions will end up working on the same supposedly mutually exclusive memory.

The impact of this bug is more severe than JDK-8366147. As we may in the best case end up crashing if we free the same physical associations, and in the worst case map already mapped memory to another address and returning it to the cache (effectively multi mapping the heap).