(assigning this to myself, but Rohitash would handle the actual fix)

We have seen this in some production environments: allocating a large direct byte buffer caused a large TTSP spike. We have seen 100+ ms spike for 100MB+ allocations. These buffers are either cached in a buffer pool, and we take the hit on occasional pool population, or they bypass the pools completely (normal for unusual buffer sizes).

One of the reasons for this spike is that `ByteBuffer.allocateDirect` calls `Unsafe.setMemory`, which does not have any safepoint polls while it is running. We should consider chunking either `ByteBuffer.allocateDirect` calls to `Unsafe.setMemory`, or chunk the `Unsafe.setMemory` itself.

Looks like all current uses we care about are in Buffers. Taking a safepoint within cleaning would open some questions whether any VM code expect to see semi-initialized area we are busy cleaning up. For Buffers, this question does not arise. Therefore, we can do the fix in Buffers first, without changing the Unsafe itself.