Reduces GC pressure and jitter in parallel queries on large multi-core machines (tested on c7a.metal-48xl with 192 vCPUs).

Key Changes

1. Off-heap Page Frame Address Cache

• PageFrameAddressCache now uses flat DirectLongList lists instead of nested LongList objects
• Reduces ~20K object allocations per 1000 frames × 105 columns to just 4 contiguous off-heap lists
• Memory footprint moves from on-heap (~3.4 MB for 1K page frames) to off-heap, eliminating GC pressure

2. Lazy MapValue Flyweights

• Decimal128, Decimal256, Long256 flyweights in map values are now lazily initialized
• Avoids allocations when these types aren't used in queries. Decimal flyweight as relatively expensive since each of them allocates multiple int[] array.

3. GroupByAllocator Improvements

• LongLongHashMap is replaced with off-heap DirectLongLongHashMap. Previously, each query worker was growing the hash map when allocating leading to lots of on-heap allocations.

4. Page Frame Size Calculation Improvements

• Page frame sizes are now calculated to avoid tiny trailing frames within a partition. Minimal page frame size is also increased 2x for vectorized non-keyed GROUP BY since these tasks a more lightweight than filter or other GROUP BY ones.

6. Work Stealing Strategy Tuning

• New config: cairo.sql.parallel.work.stealing.spin.timeout (default 50µs)
• Improvements to AdaptiveWorkStealingStrategy for better parallel execution. Namely, System.nanoTime() with configurable timeout is now used to avoid variable spinning time on different OSes and CPU architectures. Thread.onSpinWait() is used in the spin-wait loop to use PAUSE/YIELD instruction instead of "sleep(0)" system call.

7. Proper Resource Cleanup

• All classes using PageFrameAddressCache now call Misc.free(cursor) in close() methods

8. Removed Config

• Removed cairo.sql.jit.page.address.cache.threshold (no longer needed)

Benchmarks

I've run clickbench queries with 30 iterations per query on my Ryzen 7900x (12c/24t), 64GB RAM box running Ubuntu 24.04 and GraalVM CE 17.0.8.

GC Analysis Summary

Master Branch GC Metrics

• Total runtime: ~623 seconds
• GC events: 50+ (GC(0) through GC(50))
• Final heap: ~1.15GB used of ~1.18GB allocated
• GC types: Young (32), Mixed (6), Full (2), Concurrent Mark cycles (10+)

Patch Branch GC Metrics

• Total runtime: ~739 seconds
• GC events: 20 (GC(0) through GC(20))
• Final heap: ~330MB used of ~532MB allocated
• GC types: Young (14), Full (2), Concurrent Mark cycles (4)

The runtimes is different since I didn't stop the server immediately after the benchmark, so the server was idle for some time. But this shouldn't impact the end result since runtime for patch was longer.

GC Comparison

Key GC Pause Times (excluding startup Full GCs):

The patch shows a significant reduction in allocations - approximately 2.5x fewer GC cycles during benchmark execution, indicating the optimization reduces memory pressure substantially.

Query Time Analysis

Hot runs comparison according to clickbench rules (min of iterations 2-3, +10ms offset)

Note: Q28 is also tough for JVM JIT since it uses regexp_replace() SQL function, thus standard regexp library. So, the difference in that query is likely due to JVM JIT's jitter.