Some question about the JVM param -Dio.netty.maxDirectMemory=0

[horizonzy]

Expected behavior

-Dio.netty.maxDirectMemory=0 means the netty didn't record the direct memory occupation, java.nio.Bits will take over the work.
It looks better, If some code creates java.nio.ByteBuffer directly, and then clear the GC root. and then netty creates some direct memory, if the total direct memory is over the limit, JVM will do System.GC() to help to free the not reachable java.nio.ByteBuffer direct memory. It can avoid OOM killer.

If I config -Dio.netty.maxDirectMemory=0, there are some other drawbacks?
@normanmaurer @chrisvest Any ideas?

[chrisvest]

The cleaner adds a bit of overhead when freeing memory, but not much, and it won't impact the system if you use the pooling allocator.
Ideally you want to avoid frequent calls to System.gc() - it's either disabled in the JVM (so whatever it's hoping to fix, likely won't be), or it incurs a big cost to the system performance.