Java HotSpot Virtual Machine

I'm the author of a java libpcap and protocol decoder wrapper http://jnetpcap.com . The library allocates extensive amount of native memory that is outside JVM control. So far I have managed to avoid most pitfalls and things are working well.

I am redesigning low level memory management implementation for jnetpcap and would like to solicit for some ideas or insights into the best way to improve cooperation between java and native library that manages native memory.

We have not ran into too many memory related problems so far, but have encountered the following:

i) New CMS garbage collector alogirthm is not very native memory friendly although with the right JVM parameters we manage to tame it

ii) OldParallelGC seems to work the best

jNetPcap library keeps very close tabs on amount of memory allocated and freed. Native memory life-cylcles are tied to underlying java object life-cycle. When the java object is dereferenced and GCed, so is the native memory released automatically.

Here are few of my ideas and questions I have about better tieing the 2

First, the most elegant and fool proof solution would be to be able to inflate the weight of a java object or inform JVM of the external memory usage, etc.. There is however no known direct way to do that with current JNI API

Second, would be to allocate native memory by allocating java byte[] and pinning it down in memory for potentially a long period of time. This at least would go through the JVM/JNI interface to allocate the memory. This could be done in big chunks to minimize overhead. The java byte[] object could be privately hidden and not used for direct access from java. This approach has several problems though.

2a) JNI copies of the actual buffer memory - not sure how well the JVM/JNI implementation would keep track of allocated byte[] memory and JNI copies, if they were needed. Possibly allocating twice as much memory as was needed. Not to mention the overhead of copying allocated memory to temporary buffers unneccessarily for jNetPcap purposes.

2b) Another would be the memory initialization on byte[] done by JVM, which would be potentially detrimental to jNetPcap's library performance.

Third, would be to use ByteBuffer.allocateDirect, but that call doesn't track/tie java object weight with native memory allocation.

Fourth, is to invoke System.gc from jNetPcap library when certain memory parameters are met or breached. After a certain amount of native memory has been allocated call System.gc to force a clean up of unreferenced objects.

Firth is do nothing, as its done today, and twittle with various JVM and GC parameters to make it work.

I am improving jNetPcap internal memory management significantly in next generation release of jNetPcap and would like hear other opinions from JNI experts, what they would suggest is the best of the approaches listed above, given the limited capabilities of JNI API in this regard.

Sincerely,
mark
Sly Technologies
http://jnetpcap.com