GRPC: support compression

[anthony-swirldslabs]

Currently, PBJ GRPC implementation doesn't support compression. When sending datagrams, it passes 0 as a compression flag, and when receiving messages, it only supports identity encoding (meaning no compression.) This applies to both the Helidon service plugin in PBJ as well as the upcoming PBJ GRPC client implementation.

We want to support compression and have a way to enable it when using PBJ APIs for GRPC so as to reduce the network traffic as well as be compatible with 3rd party GRPC clients and services.

[jasperpotts]

We should look at supporting Gzip and Zstd compression. Then we can test to find which it optimal. There is both the algorithm performance and the implementation/JNI part which is better. Gzip is built into JDK and Zstd requires a 3rd partly JNI lib. Maybe once we get to Java 25 in early 2026 we can use new FFI to call Zstd native lib directly and make the cost cheaper. For Zstd the JDK uses which ever "zlib" native library is on the LD_LIBRARY path. The default GNU zlib on linux is slow compared to modern alternatives. So we should also test with swapping out the Zlib alternatives:

on Linux x86-64 today the “fastest but still ABI-compatible libz.so” crowd is basically:

• zlib-rs (Rust, via libz-rs-sys-cdylib) – currently the fastest API-compatible zlib implementation (especially for inflate), and explicitly designed as a drop-in libz.so replacement.
• zlib-ng (C, ZLIB_COMPAT mode) – mature, widely used fork; API/ABI compatible when built in compat mode and commonly used via LD_PRELOAD as a drop-in replacement; typically up to ~2×+ faster than stock zlib, with recent releases adding another ~10–20% on x86-64.
• Cloudflare zlib fork – older but still very fast C fork of zlib 1.2.8, API-compatible; AWS benchmarks showed it as the fastest C zlib fork at the time (~90% faster compress, ~50% faster decompress vs vanilla).

[AlexKehayov]

In the PR mentioned above (commit, comment), I benchmarked the default GZIP against ZSTD. Feel free to use any of the tests or outputs if they’re helpful.

[anthony-swirldslabs]

Based on grpc/grpc#26460 , GRPC doesn't officially support zstd or anything other than gzip for that matter. This is true for all languages including the core C GRPC implementation. However, separate Java and Go GRPC implementations (that don't rely on the core C implementation) provide experimental support for custom compressors/decompressors that applications can implement and install at runtime.

Also, a client can technically list several supported compression algorithms via its grpc-accept-encoding header, e.g. "identity,gzip,zstd". A server can also support several compression algorithms at once. As such, we don't have to make a specific choice upfront but can instead add support for other compression algorithms as that becomes feasible.

Given that zstd would ultimately require adding native code, we could start with the JDK built-in GZip support first, which would also be the most compatible solution for 3rd-party clients. Once we migrate to Java 25 and really feel that we need a better compression algorithm, then we can consider adding support for zstd as well, with an understanding that it's likely to only be supported when using PBJ on both the client and server side. We can make this future task more or less simple by designing the initial support for gzip to be extensible and generic enough to support multiple algorithms.

[anthony-swirldslabs]

Per the first two sub-tasks created for this issue, both Client and Server in PBJ now support gzip compression.

I've created a third sub-task #715 to test alternative compression algorithms to see if we can improve the performance of the default JDK-based gzip compression currently supported.