A {@link MemoryManager} implementation based on a series of shared memory pools.Each pool contains multiple buffers of the fixed length specific for this pool. There are several tuning options for this {@link MemoryManager} implementation.
- The base size of the buffer for the 1st pool, every next pool n will have buffer size equal to bufferSize(n-1) * 2^growthFactor
- The number of pools, responsible for allocation of buffers of a pool-specific size
- The buffer size growth factor, that defines 2^x multiplier, used to calculate buffer size for next allocated pool
- The number of pool slices that every pool will stripe allocation requests across
- The percentage of the heap that this manager will use when populating the pools
- The percentage of buffers to be preallocated during MemoryManager initialization
- The flag indicating whether direct or heap based {@link Buffer}s will be allocated
If no explicit configuration is provided, the following defaults will be used:
- Base buffer size: 4 KiB ( {@link #DEFAULT_BASE_BUFFER_SIZE})
- Number of pools: 3 ( {@link #DEFAULT_NUMBER_OF_POOLS})
- Growth factor: 2 ( {@link #DEFAULT_GROWTH_FACTOR}), which means the first buffer pool will contains buffer of size 4 KiB, the seconds one buffer of size 16KiB, the third one buffer of size 64KiB
- Number of pool slices: Based on the return value of
Runtime.getRuntime().availableProcessors() - Percentage of heap: 10% ( {@link #DEFAULT_HEAP_USAGE_PERCENTAGE})
- Percentage of buffers to be preallocated: 100% ( {@link #DEFAULT_PREALLOCATED_BUFFERS_PERCENTAGE})
- Heap based {@link Buffer}s will be allocated
The main advantage of this manager over {@link org.glassfish.grizzly.memory.HeapMemoryManager} or{@link org.glassfish.grizzly.memory.ByteBufferManager} is that this implementation doesn't use ThreadLocal poolsand as such, doesn't suffer from the memory fragmentation/reallocation cycle that can impact the ThreadLocal versions.
@since 2.3.11