Long story short, it was that Java21 was selecting a non-hardware backed TLS cipher which, in our application, was causing an increase in zIIP time usage.
The compression I mentioned eariler was a false positive.
I can still share the benchmark and its results if these are interesting to you.
Thanks and sorry for not responding sooner.
Original Message:
Sent: Thu April 16, 2026 02:10 PM
From: Joran Siu
Subject: zIIP usage increase between Java 8 and Java 21
@Roded Bahat: Just wanted to follow up on this -- any chance you can share your GZip benchmark or details, so we can review the zIIP usage?
Original Message:
Sent: Fri March 06, 2026 12:35 PM
From: Joran Siu
Subject: zIIP usage increase between Java 8 and Java 21
Thanks Roded for reaching out and sharing your observations with GZip performance. Can you elaborate on which specific Java versions you used in your measurements? i.e. Java version: 21.0.9.1.
I reviewed our internal benchmarking for GZip performance and see fairly comparable results between Java 8 and 17/21. Across the Java versions, the bulk of the compression operations are offloaded to a zlib implementation that makes use of zEDC on-chip accelerator on z15. What is the input sizes for your compression operations? If possible, can you share your benchmark, so I can try reproducing your observations and take a closer look?
Thanks,
Joran
Original Message:
Sent: Sun March 01, 2026 05:15 AM
From: Roded Bahat
Subject: zIIP usage increase between Java 8 and Java 21
Hello,
We're in the process of migrating from Java 8 to Java 21 on z/OS and are noticing a considerable zIIP usage increase in tests.
Our full e2e performance tests show an increased zIIP usage of around 15-20%.
JMH tests running on z/OS show a significant zIIP usage increase for some but not all benchmarks.
Specifically, benchmarks doing GZIP compression and decompression (using `_HZC_COMPRESSION_METHOD=hardware`) are showing a similar 15-20% increase zIIP time usage for the same workload.

I understand that Java 11+ on z/OS are a different JDK implementation from Java 8. We'd like to understand the reasons behind this increase and whether it's expected. Are there any recommendations for optimizing zIIP usage further when running Java 17+ on z/OS? Is this zIIP time increase expected? Anyone have any other similar benchmark results to share?
Tests ran on a z15.
This link states the following: https://www.ibm.com/docs/en/semeru-runtime-ce-z/21.0.0?topic=migrating-from-earlier-releases-semeru-certified-edition-zos
> In contrast to IBM Java 8, Semeru SDKs contain an intentional correction of what processing is dispatched to IBM z Integrated Information Processor (zIIP) that can cause an increment in general central processor (CP) usage for some specific workloads. The change is working as designed and corrects a situation in Java 8 where some processing was dispatched to zIIP when it was not zIIP eligible.
But it doesn't explain why the zIIP usage is higher in Java 17/21 compared to Java 8.
We'd appreciate any insights and comments from the IBM Java team or the community regarding this issue.
Thanks,
Roded
------------------------------
Roded Bahat
BMC
------------------------------