Releases: chrisvest/stormpot
stormpot-4.0
Stormpot 4.0
This is a major release that adds many features and upgrades the minimum Java version requirement to Java 21.
The most notable features are adding support for virtual threads.
The background allocator thread is now a virtual thread by default.
There is also a new virtual-thread-safe PoolTap
implementation available from Pool.getVirtualThreadSafeTap()
.
The claim
methods on the Pool
interface still rely on ThreadLocal
variables, however, and should be avoided if you plan to access the pool from virtual threads.
The leak detector is now off by default.
The implementation of the leak detector has also changed to make it dramatically more scalable with large pool sizes.
Speaking of large pools, it is now possible to create pools with more than 2 billion objects.
It's still recommended to keep pools as small as possible, but if you really need a very large number of objects, it's now possible.
Threaded and inline pools can now change their Allocator
implementation after they've been created.
This is useful if you want to change how objects of the same type are created.
The process of switching allocators is asynchronous and eventual, but more controlled than building this functionality into your Allocator
implementation itself.
Direct pools cannot switch allocators, because all their objects are given up front when the pool is created, and their objects are assumed to not need any significant lifecycle management from the pool.
This is a major release that breaks API/ABI compatibility, but the changes are fairly small, so migrating an existing code base should not be too much trouble.
See api-changes.json
for the complete list of compatibility changes.
What's Changed
- Upgrade to Java 21 and Remove asciidoclet by @chrisvest in #171
- Make use of new Java language features by @chrisvest in #172
- Fix test flakiness by @chrisvest in #173
- Move non-tests out of the stormpot test package by @chrisvest in #174
- Add a SlotInfo.getCreatedNanoTime and fix flaky test by @chrisvest in #175
- Separate API and internals and make tests modular by @chrisvest in #176
- Make internal classes final where possible by @chrisvest in #177
- New leak detector by @chrisvest in #178
- Add a PoolTap that support virtual threads by @chrisvest in #179
- Add Java 23 to the PR builds by @chrisvest in #180
- Update GitHub Actions by @chrisvest in #182
- Run the tests on multiple different JVM distributions by @chrisvest in #183
- Use opaque instead of volatile access to the BlazePool.shutdown field by @chrisvest in #181
- Simplify BlazePoolVirtualThreadSafeTap by @chrisvest in #184
- Remove Timeout methods that had been deprecated for removal by @chrisvest in #185
- Remove SlotInfo.getClaimCount by @chrisvest in #186
- Move the pool shutdown check out of the hottest loops by @chrisvest in #187
- Add benchmarks to the repository by @chrisvest in #188
- Marginally improve the access spread in BlazePoolVirtualThreadSafeTap by @chrisvest in #189
- Use virtual threads for Stormpot background threads by @chrisvest in #190
- Address some test flakiness by @chrisvest in #191
- Add a setting to optimise for reduced memory usage by @chrisvest in #192
- Address test flakiness in AllocatorBasedPoolTest by @chrisvest in #194
- Allow target size to be greater than 2 billion by @chrisvest in #193
- Make completion API reactive by @chrisvest in #195
- Fix new flaky test by @chrisvest in #196
- Make pools directly configurable with long size and disable leak detection by default by @chrisvest in #197
- Fix a flaky test by @chrisvest in #199
- Fix flaky leak detector test by @chrisvest in #200
- Fix all javadoc warnings by @chrisvest in #198
- Fix more flaky leak detector test by @chrisvest in #201
- Fix subscribed-to shutdown completions by @chrisvest in #202
- Fix narrow/wide type comparison alerts by @chrisvest in #203
- Cache maven dependencies to speed up builds by @chrisvest in #204
- Online allocator switching by @chrisvest in #205
Full Changelog: stormpot-3.2...stormpot-4.0
stormpot-3.2
What's Changed
- Add a tryClaim which doesn't take a Timeout by @zhenlineo in #145
- fixup Asciidoclet using include paths by @ahus1 in #141
- Add support for GraalVM by @begrossi in #144
- Fix pool shrinking with new allocations by @chrisvest in #160
- Add metrics for allocated and in-use objects by @msillence and @chrisvest in #163
New Contributors
- @zhenlineo made their first contribution in #146
- @ahus1 made their first contribution in #141
- @begrossi made their first contribution in #144
- @msillence made their first contribution in #149
Full Changelog: stormpot-3.1...stormpot-3.2
Stormpot 3.1
Stormpot 3.1 is fully backwards compatible with 3.0, but adds a number of new features:
- It is now possible to create pools with a size of zero, and to change the target size of a pool to be zero. Such pools will behave as if they are perpetually depleted, that is, as if all of their objects have been claimed. These empty pools can still have their target size increased at any later time.
- A new “inline” pool mode has been added. In this mode there is no background thread, and thus none of the background services are available. Object allocation and deallocation instead occur inline with the claim calls, hence the name. This means that these pools are lighter on CPU and memory resources.
Stormpot 3.0.1
This is a patch-release that fixes a bug where explicitly expired objects would not get to be deallocated by the configured allocator, when the pool was shut down. #135
Stormpot 2.4.2
This is a patch-release that fixes a bug where explicitly expired objects would not get to be deallocated by the configured allocator, when the BlazePool
was shut down. #135
Stormpot 3.0
Major release.
- Java 11 is now the minimum required version.
- Updated, modern, and ergonomic APIs.
- Pools are now created with
Pool.from(allocator).build()
. - There is only a single pool implementation now.
- New
Pool.of(...)
API to create a pool with pre-allocated objects, and no background thread. - Improved handling of prolonged allocation failures.
- Lower idle CPU usage.
Stormpot 2.4.1
This is a bug-fix release, that fixes a couple of cases where the background thread could get stuck at 100% CPU usage when objects are explicitly expired, or the pool is shrunk while there are poisoned slots.
Stormpot 2.4
Performance release.
- Improved performance of
Slot.release
in theBlazePool
implementation, by making it do alazySet
of the slot status, instead of acompareAndSet
. - Claimed objects can now be explicitly expired with the
Slot.expire
method, if they are discovered to have expired after they were claimed. - New
CompoundExpiration
that can combine two expiration policies.
Stormpot 2.3
Feature release:
- A new ManagedPool interface exposes a pool as an MXBean for management with JMX.
- It is now possible to enable background expiration checking, which helps reduce tail latency and prevents reallocation storms after prolonged periods of inactivity.
- It is now possible to supply a custom
ThreadFactory
that the pool can use for creating its background allocation thread. - A precise object leak detection mechanism has been added, and is enabled by default. It can detect when a program leaks claimed objects by losing the references to them.
- All the documentation is now formatted with AsciiDoctor.
- Stormpot now builds on Java 8.
- The pool no longer shuts down when an
InterruptedException
is thrown from the allocatorsallocate()
orreallocate()
methods.
Stormpot 2.2
Lots of incremental improvements:
- False sharing has been reduced in the BlazePool implementation, improving performance.
- Numerous adjustments to the BlazePool implementation to improve inlining and optimisation behaviour, improving performance.
- Fix a bug in BlazePool where the exception in a poisoned slot could bubble out through
claim()
calls more than once. - Fix a bug where the
Allocator
could eat the interrupt that was meant to signal to the allocation thread that it should begin shutting down. This signal is now no longer missed. - Poisoned slots are now proactively reallocated, if possible. This way, a temporary outage that then resolves itself, won't leave the pool full of poisoned slots that each have to bubble up through a
claim()
call before they can be reallocated. Expiration.hasExpired()
is now allowed to throw exceptions.- A new
Reallocator
API has been added. It can potentially reduce old-gen garbage accretion, in cases where Poolable instances can be reused across deallocate/allocate calls. - A new
TimeSpreadExpiration
has been added and made the default Expiration. It prevents all slots in the pool from expiring all at once. - Tons of fuzzing and stress testing have been performed. No released bugs found, though.