mirror of
https://github.com/vitorpamplona/amethyst.git
synced 2026-08-09 16:14:40 +00:00
Claude
5421b81569
Pre-fix QpackHuffman.decode allocated two boxed Integers per output character: one for the `candidate` Int passed into `HashMap<Int, Int>.get` and one for the wrapper-Integer return value. Output also went through `ArrayList<Byte>`, boxing every emitted byte as a `java.lang.Byte` (~16 bytes per output byte on a 64-bit JVM). On a typical HTTP/3 response with ~30 header values, that's hundreds of throwaway wrapper objects per request — pure GC churn on the hot path. The new layout keeps two parallel `IntArray`s per code-length: codes[len] (sorted ascending) and syms[len] (the matching symbol indices). Lookup is a primitive `IntArray.binarySearch(candidate)` — no boxing, the array stays in JIT-friendly contiguous memory, and the per-length arrays are tiny (a few entries each, since the Huffman table is sparse at any given length). Output uses a growable `ByteArray` with a manual position index rather than `ArrayList<Byte>`. Pre-grow to 2× input size as a rough upper bound — ASCII headers compress to ~62% with HPACK Huffman, so we rarely need to grow. Also fixes a latent bug: the new init loop covers lengths 5..30 (previously 5..29), restoring decoding for symbols 10 (LF), 13 (CR), 22 (DC2) which all use 30-bit codes per RFC 7541 Appendix B. Pre-rewrite the HashMap path included these via `for (sym in 0..255)` walking the full symbol table; the IntArray rewrite needed an explicit length range and accidentally cut at 29. Added a unit test exercising hand-encoded length-30 inputs to lock the fix in. Behavior verified against RFC 7541 Appendix C test vectors and the new length-30 round-trip. All 269 :quic:jvmTest tests pass. https://claude.ai/code/session_01AhGvbMV8uPRse3TmAGaddM