You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@hbase.apache.org by "Saad Ahmad Sabri (Jira)" <ji...@apache.org> on 2026/08/12 22:42:00 UTC

[jira] [Work started] (HBASE-30321) Implement GzipByteBuffDecompressor with on-heap and off-heap decompression paths

     [ https://issues.apache.org/jira/browse/HBASE-30321?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Work on HBASE-30321 started by Saad Ahmad Sabri.
------------------------------------------------
> Implement GzipByteBuffDecompressor with on-heap and off-heap decompression paths
> --------------------------------------------------------------------------------
>
>                 Key: HBASE-30321
>                 URL: https://issues.apache.org/jira/browse/HBASE-30321
>             Project: HBase
>          Issue Type: Improvement
>            Reporter: Saad Ahmad Sabri
>            Assignee: Saad Ahmad Sabri
>            Priority: Major
>
> Add GzipByteBuffDecompressor, a ByteBuffDecompressor implementation that enables GZIP
> decompression directly from/to ByteBuffer objects without intermediate byte array copies.
> Two decompression paths are supported:
> - Off-heap (direct ByteBuffer): delegates to Hadoop's native ZlibDirectDecompressor with
>   GZIP_FORMAT when native zlib is loaded
> - On-heap (heap ByteBuffer): falls back to Java's Inflater in raw DEFLATE (nowrap) mode,
>   manually skipping the GZIP header and verifying the CRC32 and ISIZE trailer fields
> Also adds GzipHFileDecompressionContext to carry per-block configuration, and
> input-length validation to reject inputs too short to be a valid GZIP member.
> The prior code had no ByteBuff-based GZIP decompression path, requiring byte array
> copies for on-heap scenarios. This eliminates those copies for both direct and heap
> buffer cases.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)