Release 1.2

Just thought I'd post some information on this new class that will be available in 1.2 release.

JMemoryPool is intended to facilitate fast native memory allocation for copying contents from libpcap round-robin buffer to something more permanent. The current alternative is to use direct ByteBuffer and do the management yourself, but this class will make it easy to copy data out of the shared buffer into heap memory.

The way it works is it allocates blocks/chuncks of memory using a normal malloc() native call and then in java space, when an object needs memory it simply allocates the amount needed out of the block/chunk. The memory is "peered" (like a pointer pointed to) with a java object which now will utilize the memory block for its operations.

JMemory class is a base class that works like a native pointer. You can redirect it to any native memory location and subclasses of JMemory will perform operations on that native memory. JMemory also has the concept of memory ownership.

So when a memory block is allocated a JMemoryPool.Block class is the owner of the entire block of memory. Any other objects that were peered with the block reference into the block, but they do not own the block so they can't free it. What they do keep is a reference to the Block object which keeps the entire Block of memory live and active. When all the references to Block are garbage collected and JMemoryPool is not using that block of memory either, that JMemoryPoool.Block is garbage collected as well which calls is free() function from the finalized() method. This way native memory by means of java references and garbage collection is allocated, tracked and eventually freed.

JMemoryPool does not reuse previously allocated blocks, once a block is used up, JMemoryPool looses reference to it, allowing it to be GCed once all the sub-allocated references to it are gone.

The algorithm is fast, may be not as resource efficient as it could be. That is where various subclasses of JMemoryPool can come in. Each providing different level of service and efficiency.

Here is an example from a javadoc I just wrote up on this:

JMemoryPool pool = new JMemoryPool();
Queue<JPacket> queue = // Some kind of user queue

public void nextPacket(PcapHeader header, JPacket shared, Strint msg) {
  // Allocate memory and copy shared packet contents, natively
  JPacket packet = new JPacket(shared, pool);

  queue.put(packet); // The rest of the user logic in the handler
}

So if a user needs to keep packets in memory more permanently there is no way (currently) of getting around the fact that the content has to be copied from libpcap buffer to something more permanent. Therefore with JPacket object (also new in 1.2 - a decoded packet) is created, next memory allocated for it to hold decoded packet state and data buffer then the shared libpcap packet transfers (copies) its state and data to newly allocated memory. Behind the scene this is all native copying and memory allocation.