With JDK-8350441, ZGC now relies more heavily on malloc in allocating and freeing native memory for the heap regions it uses, called pages.

The SPECjvm2008-Derby-ZGC benchmark simulates numerous transactions, resulting in a significant amount of memory allocation that is quickly reclaimed by the GC, which characterizes the benchmark as "allocation heavy". The regression is specifically observable on Windows, where the default malloc implementation is notoriously slow.

One area in which we can see increased latencies is in ZPageAllocator::free_page(), which frees heap regions (pages) that have become empty. On Linux we spend about 4x more time inside this function after JDK-8350441, while on Windows we spend about 360x more time. Spending more time in ZPageAllocator::free_page() is not by itself unexpected, but on Windows this slowdown is unproportionally large. Our hypothesis is that the malloc implementation on Windows effectively serialises its operations under heavy load, which results in very slow progress among threads when there is high contention on malloc/free. We can see some affect on other subsystems in the JVM using malloc during the same time ZGC has increased usage of malloc/free as well.