# Java CPU range configuration review

The Java settings loader could exhaust the heap while expanding a range of only
two entries. For `LibhftWorkerCores=2147483646-2147483647`, its signed `int` loop
index wrapped from the upper endpoint to `Integer.MIN_VALUE`, which still passed
the loop condition. A standalone probe compiled the actual settings class and
reproduced `OutOfMemoryError` with a bounded 32 MiB heap. This is a startup
configuration defect, not a finding about incoming FIX messages.

## Correction and verification

The expansion index is now a `long`. Each appended value remains an `int`, but
the loop can advance beyond the largest int endpoint and terminate normally.
The same probe now returns exactly `[2147483646, 2147483647]` with the same heap
limit. No session loop, synchronization, allocation on the message path, JNI or
affinity implementation changed.

Two file-loader regressions cover singleton and two-entry ranges at the integer
maximum, a maximum-ending range inside a mixed list, ordinary range order and
duplicates, malformed entries, out-of-int tokens and the existing descending-range
behavior. The five selected Maven suites passed 144 tests with zero failures,
errors or skips: settings 106, throttle 19, TX queue 9, send batching 6 and
command admission 4. Both changed files passed the public-export scan with zero
findings. These are functional tests under an isolated CPU lease alongside the
other session's shared-core conformance run, not latency measurements.

The first Maven run exposed a pre-existing missing `assertThrows` import in the
file-store alias test introduced by `a21448dfc`. After correcting the import,
that fixture also needed the mandatory sender and target IDs before it could
reach its intended durability assertions. Both corrections are confined to the
claimed settings test; production file-store semantics are unchanged. The failing
logs are retained separately from the final passing run.

## Evidence and limits

`~/archive/libhft/core-list-overflow-review-20261003/` keeps the baseline source,
probe, failing and passing logs, Maven XML reports, exact patch and source pins.
The baseline settings source from `30a7a8a85` has SHA-256
`d27b27c436f0baeed729caa5caa3c08dc33dd6c56426f86c1c8333991852195b`.

This preserves the parser's existing acceptance policy; it does not establish
that a parsed CPU ID exists or is usable on the current host. It also introduces
no new list-size policy: genuinely enormous ranges still allocate in proportion
to their requested entry count. The fix prevents accidental infinite expansion
of a small range, without changing those separate configuration policies.

## Complete Java suite verification

The complete Maven test run at `201b30da81f15164e790f696f8fd09831fdd542b`
passed 2,438 tests in 243 suites, with zero failures, errors or skips. JNI loading
was required, and the native library was freshly built with TCPDirect and
SocketXtreme support. Its SHA-256 was
`ecadd02d203c778ee1cde51201681ae19b6b089d61599c18754fffe7a2737071`.
This is a source-pinned functional run, not a NIC or latency benchmark.

The run archive at `~/archive/libhft/java-full-review-20261003/` includes the
build/test script, source pin, library hash, log, JSON counts and all 243 fresh
XML reports. The collector excluded nine stale reports predating this run's JNI
build rather than including them in the passing count. During the slow live
allocation tests, the run's driver and peer threads were observed on the same
isolated CPU. They were then placed on cores 9 and 10 within this session's
reserved pool; before/after placement and a thread dump are retained. The
allocation assertions passed, but this change prevents treating the run's wall
time as a comparative performance result.

Native FIXP liveness changes landed concurrently after that full-suite source
pin. The 2,438-test result is not claimed for those later changes. After merging
through `0ca7a23e2`, a second fresh JNI build and 13 focused settings, queue,
throttle and native FIXP suites passed 178 tests with zero failures, errors or
skips. The second library's SHA-256 is
`5233dd91899bfc9de77c1b377170984eb1d601b367fd71d803ecaecfe0f74698`;
the focused JSON and log are kept with the CPU-range review evidence.

After merging through `0890ba884`, those native checks plus the new Java FIXP
liveness suites passed 199 tests without failures, errors or skips. C++
multi-acceptor liveness then landed separately; after merging it, the five
settings, throttle and queue suites were rerun and passed all 144 tests. The
CPU-range fix was published as `5c593aafe`. The archive keeps both final logs and
their source pins; the 199-test result is not claimed for later native changes.