Applications that heavily use NIO, like some Netty-based ones, sometimes benefit from more direct memory as the overall memory available to the JVM increases. This is because direct memory does not have, in itself, garbage collection, but rather it relies on APIs like Cleaner or other phantom reference-based ones to free direct memory as a consequence of evicting objects from heap (like ByteBuffers).
We actually have one such use-case in the Instana Agent, which is a Netty-based application that uses significantly more direct memory than most Java apps. When the Instana Agent runs in a container, we usually want to allocate roughly 1MB to direct memory for each 3MB to the heap, although heavy usage of some functionality skews that ratio one way or the other.
We have forked the memory calculator for tweaking it to our needs, but we'd be happy to contribute back if this feature is interesting to this project.
Applications that heavily use NIO, like some Netty-based ones, sometimes benefit from more direct memory as the overall memory available to the JVM increases. This is because direct memory does not have, in itself, garbage collection, but rather it relies on APIs like Cleaner or other phantom reference-based ones to free direct memory as a consequence of evicting objects from heap (like
ByteBuffers).We actually have one such use-case in the Instana Agent, which is a Netty-based application that uses significantly more direct memory than most Java apps. When the Instana Agent runs in a container, we usually want to allocate roughly 1MB to direct memory for each 3MB to the heap, although heavy usage of some functionality skews that ratio one way or the other.
We have forked the memory calculator for tweaking it to our needs, but we'd be happy to contribute back if this feature is interesting to this project.