Released: Stormpot 3.0
Version 3.0 of Stormpot, my high-performance Java object pooling library, has been released to Maven Central. You can add it as a Maven dependency to your projects like this:
<dependency>
<groupId>com.github.chrisvest</groupId>
<artifactId>stormpot</artifactId>
<version>3.0</version>
</dependency>The full documentation can be found here: http://chrisvest.github.io/stormpot/
Stormpot 3.0 is a major release, and brings breaking changes to integrators. First of all, Stormpot now requires Java 11. Stormpot fully supports the Java Platform Module System, and exposes itself as a stormpot module, and no longer makes use of the sun.misc.Unsafe class, or any reflection hacks. Performance is the same as the 2.4 release.
Another notable change is how the pool is configured and constructed. Instead of creating a Config object and calling the BlazePool constructor, you now have to call the Pool.from(allocator) method, which returns a PoolBuilder, and then you call build() on that to get the Pool instance. This is simpler than it sounds, because the API will guide you on your way. There is also only one pool implementation now, so integrators no longer have to decide between BlazePool or QueuePool.
There are fewer interfaces to deal with in 3.0. Previously, there were LifecycledPool and ResizablePool interfaces, etc. Now the Pool API has all the methods, with the exception of those on the ManagedPool interface, which still remains separate.
There is a new Pool.of(...) constructor method, which directly takes the objects to be pooled as arguments, and returns a pool for them. Because the life of these objects are managed externally, these directly-allocated pools will never expire or deallocate their objects. Because of this, they have no need for a background thread, and this makes them extremely light weight! One draw-back of these pools is that — since they don’t know how to allocate or deallocate objects — the pool size cannot be changed once the pool has been created.
A new PoolTap concept has been introduced. The PoolTap API only consist of the claim and related methods. A Pool instance exposes two types of taps. The first kind of tap uses an internal ThreadLocal for caching and is therefor thread-safe. This way it works just like directly accessing the pool itself. The other kind of tap is not thread-safe, but is intended to be used and owned by only one thread at a time. Hence this second kind of pool tap is called thread-local — the tap itself is meant to be local to the thread, and not shared. Using the thread-local — rather than thread-safe — pool tap, removes a ThreadLocal look-up from the fast-path of the claim method. This may have a negligible performance boost, but the main purpose is for environments whereThreadLocal objects are causing trouble, such as in web containers. In these cases, the integrators can let their containers manage the thread-local pool taps for them.
The handling of prolonged allocation failures has been improved in Stormpot 3.0. This further drops the CPU usage in an idle pool where one or more of the slots failed to allocate. It is also possible to further reduce the background CPU load, by configuring a higher background expiration check delay on the PoolBuilder. Background expiration checking is also enabled by default, now.
Expiration implementations are now easier to build, using the suite of combinator methods on the interface. The TimeSpreadExpiration that was the default and preferred expiration in previous versions, is now available through the Expiration.after() methods. Slow expiration implementations can have their check frequency reduced by using the Expiration.every()combinator methods.
Past, Present and Future
Stormpot 3.0 took a very long time to finish for two reasons. The first is the too-little-time-too-much-to-do situation that I think many of us are dealing with. The second is that all of the javadocs in Stormpot were written in asciidoctor, and rendered with a custom doclet. In order to upgrade Stormpot to Java 11, this doclet also had to be upgraded. This was a very time consuming process, but this is work that is now done. Stormpot releases should be more frequent in the future, though, as always, no guarantees are given. The next release will be 3.1.
