question: public int alloc ( final RWStore store , final int size , final IAllocationContext context ) { try { if ( size <= 0 ) throw new IllegalArgumentException ( "Allocate requires positive size, got: " + size ) ; if ( size > m_size ) throw new IllegalArgumentException ( "FixedAllocator with slots of " + m_size + " bytes requested allocation for " + size + " bytes" ) ; if ( m_freeBits == 0 ) { throw new IllegalStateException ( "Request to allocate from " + m_size + "byte slot FixedAllocator with zero bits free - should not be on the Free List" ) ; } int addr = - 1 ; if ( m_size <= m_store . cSmallSlot ) { return allocFromIndex ( size ) ; } final Iterator < AllocBlock > iter = m_allocBlocks . iterator ( ) ; int count = - 1 ; while ( addr == - 1 && iter . hasNext ( ) ) { count ++ ; final AllocBlock block = iter . next ( ) ; checkBlock ( block ) ; addr = block . alloc ( m_size ) ; } if ( addr != - 1 ) { addr += 3 ; if ( -- m_freeBits == 0 ) { if ( s_islogTrace ) log . trace ( "Remove from free list" ) ; removeFromFreeList ( ) ; if ( m_freeList . size ( ) > 0 ) { if ( s_islogDebug ) { final FixedAllocator nxt = ( FixedAllocator ) m_freeList . get ( 0 ) ; log . debug ( "Freelist head: " + nxt . getSummaryStats ( ) ) ; } } } addr += ( count * 32 * m_bitSize ) ; final int value = - ( ( m_index << RWStore . OFFSET_BITS ) + addr ) ; if ( m_statsBucket != null ) { m_statsBucket . allocate ( size ) ; } return value ; } else { StringBuilder sb = new StringBuilder ( ) ; sb . append ( "FixedAllocator returning null address, with freeBits: " + m_freeBits + "\n" ) ; for ( AllocBlock ab : m_allocBlocks ) { sb . append ( ab . show ( ) + "\n" ) ; } log . error ( sb ) ; return 0 ; } } finally { if ( s_islogDebug ) checkBits ( ) ; } }
target:  The introduction of IAllocationContexts has added some complexity to the older concept of a free list.  With AllocationContexts it is possibly for allocator to have free space available but this being restricted to a specific AllocationContext. <p> In addition to the standard free allocation search we want to add a "density" restriction for small slots to encourage the aggregation of writes (by increasing the likelihood of sibling slot allocation). <p> There is some "Do What I mean" complexity here, with difficulty in  determining a good rule to identify an initial allocation point.  There is a danger of significantly reducing the allocation efficiency of short transactions if we too naively check committed bit density.  We should only do this when identifying the initial allocation, and when the allocIndex is incremented.