NIO.2 and GC fragmentation

[Mark Thornton]

Leon Finker wrote:
> Hi,
>
> While at it, I decided to comment on the other half of the problem that
> existed in early .NET versions and sockets API: GC fragmentation. When
> calling out to OS native API, the buffers that we pass in from .NET world
> are "pinned" and used directly by the underlying OS native API. What this
> means is that GC is unable to move these buffers around in order to compact
> the heap until native API returns to managed world. Since on a server
> thousands of buffers can be pinned while waiting for I/O to happen this
> caused a great deal of heap fragmentation. 
>
> Is it correct to assume that Java in a sense also "pins" the Java direct
> buffers that it uses in JNI and those prevents GC from moving these buffers
> and compacting the heap until native API returns? Thank you in advance for
> feedback
>
>   
Java direct buffers aren't allocated from the Java heap (the buffer 
itself that is, not the object which wraps it)! They are allocated using 
the OS runtime and don't affect the garbage collector. The JVM has limit 
(default 64MB I seem to recall) of total direct buffer allocation. What 
can be a problem is disposing of them --- the memory is released by a 
cleanup thread after the object has become unreachable. However you can 
run short of memory for direct or memory mapped buffers, while still 
having plenty of free space in the Java heap.

Mark Thornton