Overview

To achieve zero garbage operation in steady state the platform pools objects to avoid allocations. Pools created by the platform start out with no objects preallocated, so it is important for applications that drive warmup traffic at startup not only to allow for JIT optimization to kick in, but also to make sure pools are grown accordingly. Applications should push traffic at rates higher than expected peak volume to ensure that pools sizes grow to a level that can accommodate spikes in traffic. 

There are cases where it is desirable to manually configure pool parameters sch as:

• Cases where is challenging to drive warmup traffic to the point where pools reach they optimal capacity. In such cases it is desirable to manual configure a pool for preallocation.
• Pools that are used purely in a preallocated fashion. For example in applications that use expect a given number of Order objects in a day may want to start with those objects preallocated
• In some cases initial bursts of traffic at application startup cause pools of seldom used types to grow to a large size, but then remain dormant taking up wasted memory. In this case it would be desirable to limit the pools capacity. 

Configuring Pools

This can be achieved by setting properties of the form "nv.pool.<poolKey>.propertyName" where

poolKey is:
the name of the pool as reported in pool stats without the trailing pool ".<instanceId>" suffix.

propertyName is one of the bean properties on UtlPool.Params:

• initialCapacity - The initial size of the array to hold pool items that are not in use. 
• maxCapacity - The maximum number of slots for items not in use. If an item is returned to a pool and they are no slots left it is evicted and becomes eligible for garbage collection. 
• threaded - Whether or not the pool will be safe for access by multiple threads. 
• preallocate - When true, pool is filled to its initial capacity with newly created items when the pool is created. When false, items are created on demand. 
• detachedWash - When items are returned to a pool its fields are reset. When true this makes items returned to the pool eligible for cleanup on a detached thread. 

For example, pool stats may show stats for the packet backing an XBuf generated message as "packet.MyMessageXbufPacket.71.1.216". The key to use for the pool would thus be "packet.MyMessageXbufPacket.71.1", and the pool could be configured for preallocation in DDL as: