I've done a mental walkthrough of StatelessInstanceInterceptor.invoke() and seems
like there might be a leak:

1st ejb3 stateless invocation:

call StatelessInstanceInterceptor.invoke()
call pool.get()

-> start ThreadlocalPool.get()
// currentBeanContext is null so
create new BeanContext and add it to InfinitePool.active
return created BeanContext
// currentBeanContext is still null upon return
-> end ThreadlocalPool.get()

call ejb.invokeNext();
call pool.release(ctx);

-> start ThreadlocalPool.release()
//currentBeanContext is null so
call currentBeanContext.set(ctx);
-> end ThreadlocalPool.release()

end StatelessInstanceInterceptor.invoke()
// created BeanContext is still in InfinitePool.active
// currentBeanContext is not null now and contains the ctx created for this invocation

2nd ejb3 stateless invocation:

call StatelessInstanceInterceptor.invoke()
call pool.get()

-> start ThreadlocalPool.get()
// currentBeanContext is not null
assign currentBeanContext.get to ctx
set currentBeanContext to null
return ctx
// currentBeanContext is null upon return
-> end ThreadlocalPool.get()

call ejb.invokeNext();
call pool.release(ctx);

-> start ThreadlocalPool.release()
//currentBeanContext is null so
call currentBeanContext.set(ctx);
-> end ThreadlocalPool.release()
end StatelessInstanceInterceptor.invoke()
// BeanContext is still in InfinitePool.active
// currentBeanContext is not null now and contains the ctx created for this invocation

Looks to me like there's a leak as active contexts are never removed from InfinitePool.active List
because currentBeanContext is always null when it the call lands on pool.release(ctx).

Screenshots of the memory analysis can be found in the support case.