Talk: Who moved my (Java) heap?
A talk delivered at JCON USA / IBM TechXChange on October 26, 2026.
How do you find out if your basement is flooded?
The talk started out with this simple question for the audience.
The simple answer which everyone knows is “you look.”
The Analogies
We used the following analogies to help both developers and non-developers in the talk connect with the topic and content. The analogies worked very well.
- A Mem Haul truck hauling away your available memory
- Flooding basement — same happens on Java heaps with object waste
- X-Ray Technology — Decades old CLI tools including
jps,jmap,jcmd - MRI Technology — Precision tools including Java Object Layout (JOL) and Java Microbenchmark Harness (JMH) which are OpenJDK projects.
There are three types of things to consider when investigating memory impacts.
- Movers — In memory data structures that occupy long lived memory. These things move the baseline of our heap.
- Shakers — Short-lived processing objects that cause volatility spikes in our heap.
- Movers and Shakers — Short-lived processing objects that result in potentially medium to long term data structures
There are JOL, JMH, and unit tests covering all three of these
The Code Comparisons
At a high level we are comparing the memory efficiency and performance of Java Stream and Eclipse Collections for various patterns. Eclipse Collections has multiple solutions to each problem including a utility class called Iterate with eager methods, eager methods directly on data structures, and lazy methods via LazyIterable. LazyIterable is the closest apples to apples comparison with Java Stream.
Get Donald Raab’s stories in your inbox
Join Medium for free to get updates from this writer.
For some of the tests there are JOL tests for memory, JMH tests for performance and allocation, unit tests. There are also JOL assertions (JolMemoryTestUtil) which may be useful for other projects to test and assert expected memory. There is a link to each of the packages on GitHub for Movers, Shakers, and Movers and Shakers below.
Data Structures — “Movers”
- Java Collections -> Eclipse Collections -> Eclipse Collections Primitive
ArrayList->FastList->IntArrayListHashSet->UnifiedSet->IntHashSetHashMap->UnifiedMap->IntObjectHashMap/ObjectIntHashMap/IntIntHashMap
Data Processing — “Shakers”
Utility Comparison — Java Stream -> Eclipse Collections Iterate
anyMatch->anySatisfy/anySatisfyWithCollectors->Collectors2filter().findFirst()-> detect /detectWithfilter().count()->count/countWith
Eager and Lazy Comparison — Java Stream -> Eclipse Collections eager and LazyIterable
anyMatch->anySatisfy/anySatisfyWithCollectors->Collectors2filter().findFirst()-> detect /detectWithfilter().count()->count/countWith
Data Processing and Data Structure — “Movers and Shakers”
filter().collect(Collectors.toSet())->select().toSet()collect(Collectors.groupingBy(Collectors.toSet()))->groupBy(MutableSetMultimap)Map.copyOf(collect(Collectors.groupingBy(Collectors.counting())))->countBy
The Freebie
Upgrade to Java 25+ and enable Compact Object Headers (COH). Save 10–15% on your occupied heap size. If you’re on Java 27+, nothing to do as COH is now a default feature.
A Mind Map of the talk
The AI Angle
No talk today would be complete without AI. All of the tools and approaches covered in this talk can be packaged up as AI skills. CLIs work great with AI, and Java has a decent number of CLI tools included with every Java distribution for decades. JOL and JMH are also easy to have AI generate and analyze benchmarks. I’ve been doing this successfully for the past year and discovering a lot of the issues we talk about in Java Stream.
The Slides
The following is the GitHub link to the slides and code used in the talk.
Check out the repo and open index.html in a browser in either of these two directories
- Dark mode slides —
assets->pres-dark - Light mode slides —
assets->presentation
The Verdict
The audience responded very well to the topic. Both developers and non-developers found the content engaging and easy to understand. There is a tremendous amount of detail in the slides and code, and the slides can be read without having to watch the talk. This turns out to be great, because this talk was not recorded.
The benchmarks compare Java Stream solutions and Eclipse Collections eager and lazy solutions.
Escape Analysis Surprise
I learned in the past two weeks how to see the effects of Escape Analysis in JMH benchmarks. The following slide is a spoiler which you can check out on your own in the slides.
Spoiler: Escape analysis has no impact on Java Stream.anyMatch() in our tests. Don’t trust us though. Validate with your own tests.
As an addendum to the talk, which specifically addresses the Escape Analysis feature in more detail than we do in the talk, I would recommend reading the following blog.
The Future
I can’t predict the future, but 10/10 I would be willing to give this talk again at other conferences. I think Java related conferences would do well to include advanced technical content like this. This talk enables developers to learn and incorporate strategies to keep their production Java deployments from getting out of control and occasionally requiring a random increase in memory as data volumes increase “just because.” Simple increasing memory is like paying for flood insurance. We are not in that business. We want to promote flood awareness and flood prevention as habits and solutions.
Thank you to JCON USA and IBM TechXChange for accepting our talk. We had a lot of fun preparing for the talk and giving it.
Thanks for reading, and I hope you enjoy the slides and can join us for discussions at future conferences.
I am the creator of and committer for the Eclipse Collections OSS project, which is managed at the Eclipse Foundation. Eclipse Collections is open for contributions. I am the author of the book, Eclipse Collections Categorically: Level up your programming game.
