feat: upgrade llama.cpp from b10902 to b10903

CLAUDE.md

@@ -6,7 +6,7 @@ This file provides guidance to Claude Code (claude.ai/code) when working with co
 
 Java bindings for [llama.cpp](https://github.com/ggerganov/llama.cpp) via JNI, providing a high-level API for LLM inference in Java. The Java layer communicates with a native C++ library through JNI.
 
-Current llama.cpp pinned version: **b10902**
+Current llama.cpp pinned version: **b10903**
 
 ## Upgrading CUDA Version
 
@@ -502,7 +502,7 @@ needs no extra step here, `build-webui` re-reads the tag and rebuilds the matchi
 ships no UI):
 ```bash
 # needs node/npm + network for the asset build; the embed step is plain cmake -P
-git clone --depth 1 --branch b10902 https://github.com/ggml-org/llama.cpp /tmp/lc
+git clone --depth 1 --branch b10903 https://github.com/ggml-org/llama.cpp /tmp/lc
 ( cd /tmp/lc/tools/ui && npm ci && npm run build )
 mkdir -p webui-generated /tmp/ui-gen
 cmake -DUI_SOURCE_DIR=/tmp/lc/tools/ui -DUI_BINARY_DIR=/tmp/ui-gen \
@@ -542,7 +542,7 @@ cache lives in **Depot Cache** over sccache's **WebDAV** backend:
 - `SCCACHE_WEBDAV_TOKEN: ${{ secrets.DEPOT_TOKEN }}` — a Depot **organization** token, stored
   as the repo secret **`DEPOT_TOKEN`**.
 
-Because `sccache` is **content-addressed** and llama.cpp is pinned (`GIT_TAG b10902`), the
+Because `sccache` is **content-addressed** and llama.cpp is pinned (`GIT_TAG b10903`), the
 ~280 upstream object files are byte-identical every run, so a warm cache recompiles only the
 *changed* files. Depot's cache is **shared across all branches** (unlike GitHub's
 per-branch `actions/cache`), so every branch builds incrementally; a `b<nnnn>` version bump
@@ -1535,7 +1535,7 @@ ctest --test-dir build --output-on-failure -R "ResultsToJson"
 
 #### Upstream source location (in CMake build tree)
 
-llama.cpp is fetched via CMake FetchContent, pinned to `GIT_TAG b10902`.
+llama.cpp is fetched via CMake FetchContent, pinned to `GIT_TAG b10903`.
 
 **GoogleTest** is a separate `BUILD_TESTING`-only FetchContent (`GIT_TAG v1.17.0`), used solely
 by the `jllama_test` C++ unit-test binary — not by the shipped library, and not coupled to the

README.md

@@ -11,7 +11,7 @@
 **Build:**  
 ![Java 8+](https://img.shields.io/badge/Java-8%2B-informational)  
 ![Platform](https://img.shields.io/badge/Platform-Linux%20%7C%20macOS%20%7C%20Windows%20%7C%20Android-lightgrey)  
-[![llama.cpp b10902](https://img.shields.io/badge/llama.cpp-%23b10902-informational)](https://github.com/ggml-org/llama.cpp/releases/tag/b10902)  
+[![llama.cpp b10903](https://img.shields.io/badge/llama.cpp-%23b10903-informational)](https://github.com/ggml-org/llama.cpp/releases/tag/b10903)  
 [![JPMS](https://img.shields.io/badge/JPMS-modular%20JAR-25A162)](https://openjdk.org/projects/jigsaw/)  
 ![JUnit](https://img.shields.io/badge/tested%20with-JUnit6-25A162)  
 [![JSpecify](https://img.shields.io/badge/JSpecify-1.0.0%20%40NullMarked-25A162)](https://jspecify.dev)  

docs/history/llama-cpp-breaking-changes.md

@@ -706,3 +706,5 @@ Used during `llama.cpp` version bumps: when upgrading, scan this file from the r
 | b10878–b10883 | patches + upstream verification | **All nine patches apply, and not one needed refreshing — every patch-target file is byte-unchanged in the range.** Checked file by file rather than inferred from the aggregate: `common/arg.cpp`, `common/arg.h`, `common/peg-parser.cpp`, `tools/server/server.cpp`, `tools/server/server-context.{cpp,h}`, `tools/server/server-models.cpp`, `src/llama-model.{cpp,h}` and `tests/CMakeLists.txt` all report no diff between the two tags. The two standing drop-checks were still run against the pristine tag, because the fail-loud applier detects "does not apply" but never "upstream already fixed this": `0001` — `common_params_parse_main` appears **0 times** in `b10883:common/arg.h` and the `#ifdef _WIN32` `argv = utf8.ptrs.data()` override is still at `common/arg.cpp:1282`, so it stays; `0012` — `b10883:src/llama-model.cpp:1489` still normalises with a bare `splits[i] /= split_sum;` and has **no `split_sum == 0` guard**, so the CLAUDE.md instruction to *drop rather than refresh* does not fire. Verified for real: `rm -rf build && cmake -B build -DBUILD_TESTING=ON` through the real `FetchContent` path, configure clean, stamp written at head `91f6a6cf361385700bbe15981f0f39909df77498` (= `b10883`) with **all nine hashes recorded**; full `cmake --build --config Release` clean; `ctest` **531/531**. That total is 4 up from b10878 because this is the first bump after `test_model_flags.cpp` landed — and it is the first bump whose **flag contract** was machine-checked rather than reasoned about: `JavaCliFlagContract` re-derives the 138 flags the Java layer emits and re-runs them through `common_params_parser_init(params, LLAMA_EXAMPLE_SERVER)` at the new tag, so "`arg.cpp` is unchanged, therefore the registered option set is unchanged" is now an assertion the build makes, not an inference a reviewer makes. `nm -D` on the fresh `libjllama.so` reports **40** `Java_*` exports. `mvn -pl llama clean test -Dtest=NativeLibraryLoadSmokeTest` **4/4, 0 skipped**, including `nativeBuildInfoMatchesPinnedVersionConstant` — the end-to-end proof that the four pin sites and the linked binary agree (`clean` is required: javac inlines `LLAMA_CPP_VERSION` into the test class and Maven's incremental compile cannot see that dependency). Full `mvn test`: **1759 tests, 0 failures, 0 errors**. |
 | b10883–b10902 | `src/llama-model.{cpp,h}` (**additive only**: two new `llm_type` enumerators, `LLM_TYPE_3B_A800M` for Granite3 MoE and `LLM_TYPE_32B_A9B` for Granite4 Hybrid, plus their `llm_type_name` cases — four lines total, far from `patches/0012`'s hunks), `common/speculative.cpp` (**#28587**: the DFlash draft implementation now skips an M-RoPE image whose rows are all pinned to one position, because a windowed draft cache cannot free cells for it — internal to `common_speculative_impl_draft_dflash`, **no signature moved**, so `common_speculative_init` / `_draft` / `_accept` are untouched), `src/llama-memory-hybrid-idx.cpp` (**#28330**: sets `n_embd_head_{k,v}_mla_impl` so `llama_kv_cache` skips allocating the unused V cache for the indexer — three lines, internal), `src/models/*` (**#28643/#28669**: Granite-family parameter-count fix and dead-switch-branch cleanup across bert / jina-bert-v3 / nomic-bert{,-moe} / granite{,-hybrid,-moe}), `tests/test-backend-ops.cpp`, `ggml/src/ggml-{opencl,vulkan,cpu}/**`, `.github/**`, `scripts/make-release-checks.sh`, `conversion/nemotron.py`. 30 files, 1106 insertions, 423 deletions, **110 KiB** raw. | **No project-source change, and not one file on the priority review list moved.** Zero files under `common/*.h`, `include/`, `tools/server/` or `tools/mtmd/`, so every row of the API-compatibility table is vacuously satisfied and the three mechanical server-contract greps have **no input to compare** — the request-field set, its `set_hard_limits` bounds and the emitted response keys cannot have moved. The one `common/` file in the range is `speculative.cpp`, an implementation TU compiled by upstream, not a header this project includes. **Sizing, and why it was bumped straight through at 110 KiB.** The runbook's threshold is 100 KiB, so `llama-next-version.sh` proposed an intermediate stop at b10901 (87 KiB). The 23 KiB that pushes b10902 over is **entirely** `ggml/src/ggml-opencl/**` — one `CMakeLists.txt` line, `ggml-opencl.cpp`, and a new `gemv_noshuffle_q4_0_f32_32b_trans.cl` kernel (#28268). Bucketed by top-level directory the whole range is 998 lines of `ggml/src` backend internals against **93 lines across 13 files** of everything this project actually compiles, links or includes — so chunking would have split a backend-kernel addition in half and reviewed nothing extra. Same call, and same reasoning, as the b10870–b10878 row. **Worth knowing for the s390x job:** two of the 19 commits are upstream's own `ggml-cpu` s390x work (#28667 q4_0 repack, #28606 Q1_0 vector intrinsics, 291 new lines under `ggml/src/ggml-cpu/arch/s390/`). Those are upstream's big-endian kernels; the `build-linux-s390x` job's qemu `ctest` gate covers *this project's* endian-sensitive layer (the little-endian WAV writer, the JSON/token/embedding transforms), which the range does not touch. |
 | b10883–b10902 | patches + upstream verification | **All nine patches still apply, and `0001`, `0010` and `0012` are all still required.** Only one patch target moved in the range — `src/llama-model.{cpp,h}` (`0012`) — and its diff is the two additive enumerators above, nowhere near `load_tensors`. The other eight targets (`common/arg.{cpp,h}`, `common/peg-parser.cpp`, every `tools/server/*`, `tests/CMakeLists.txt`, `vendor/*`) are **byte-unchanged**, verified by diffing those paths explicitly rather than inferred from the aggregate. All three standing drop-checks were run against the pristine tag, because the fail-loud applier detects "does not apply" but never "upstream already fixed this": **`0001`** — `common_params_parse_main` appears **0 times** in `b10902:common/arg.h` and the `#ifdef _WIN32` count-guarded `argv = utf8.ptrs.data()` override is still at `common/arg.cpp:1282`; **`0010`** — `b10902:tools/server/server-context.cpp:4554` still emits `{"vocab_type", meta.model_vocab_type}` uncast, so the `common_json` enum-to-bool trap is still live; **`0012`** — `b10902:src/llama-model.cpp:1491` still normalises with a bare `splits[i] /= split_sum;` and carries no `split_sum == 0` guard. Verified for real: `rm -rf build` then `cmake -B build -DBUILD_TESTING=ON` through the real `FetchContent` path, configure clean, stamp written at head `df03399b885831b2a1603b3abb0d8c156808e363` (= `b10902`) with **all nine SHA-256 lines**; full `cmake --build --config Release` clean; `ctest` **537/537**, including the seven `LlamaModelSplits.*` cases that are the only place `0012`'s two extracted functions are linked in CI, and the six `test_wire_contracts.cpp` cases whose configure-time `OAI_LAYER` reader sweep re-ran against b10902's sources (138 CLI / 57 request / 15 trainer names extracted, unchanged). `nm -D` on the fresh `libjllama.so`: **40** `Java_*` exports, **0** C++-mangled ones. `mvn -pl llama clean test -Dtest=NativeLibraryLoadSmokeTest` **4/4, 0 skipped**, including `nativeBuildInfoMatchesPinnedVersionConstant` — the end-to-end proof that the four pin sites and the linked binary agree. Run with `clean`: `LLAMA_CPP_VERSION` is a compile-time constant javac inlines into the test class, and Maven's incremental compilation cannot see that dependency. |
+| b10902–b10903 | `ggml/src/ggml-vulkan/vulkan-shaders/argsort.comp` + `argsort_large.comp` — and nothing else. One commit (**#28705**, "vulkan: fix data race and OOB access in argsort(large)"), 2 files, 21 insertions, 12 deletions, **3 KiB**. | **The smallest bump in this file's history, and a genuinely empty review surface.** Upstream fixes two defects in the Vulkan bitonic argsort. The *OOB read*: the initialising write now leaves `value.y` at 0 for a padded column instead of reading `data_a[row_offset + col]` past `p.ncols` (both shaders). The *data race*: the compare-exchange body is hoisted **inside** the `ixj > col` guard, so only one thread of each pair touches the two shared-memory slots — previously both threads ran the read-modify-write and only the final store was guarded, i.e. the partner thread read `dst_row[idx_0]`/`dst_row[idx_1]` concurrently with its own unsynchronised write. No C++, no header, no build-system file, no Python pin. Every row of the API-compatibility table is **vacuously satisfied** and the three mechanical `tools/server/` contract greps have **no input** — for the second bump running. Well under the 100 KiB chunking threshold, so no chunking question arises. **Where it does land:** GLSL under `ggml/src/ggml-vulkan/vulkan-shaders/` is compiled by `glslc` at build time and embedded, so the change reaches exactly the three Vulkan classifier artifacts (`vulkan-linux-x86-64`, `vulkan-linux-aarch64`, `vulkan-windows-x86-64`). All three are **build-only** jobs on GPU-less runners, so CI proves the shaders still compile, not that the race is fixed — that needs real Vulkan hardware, which no job here has. The default JAR and every non-Vulkan classifier are bit-for-bit unaffected by this range. |
+| b10902–b10903 | patches + upstream verification | **All nine patches apply untouched, and the intersection with `patches/` is empty by inspection rather than by aggregate:** the two changed files are Vulkan shaders, which no patch in this repo touches. The three standing drop-checks were nevertheless run against the pristine tag rather than waved through on that basis — the fail-loud applier detects "does not apply" but never "upstream already fixed this", and a drop-check firing is a reason to **delete** a patch, which no amount of "the diff is small" substitutes for. **`0001`** — `common_params_parse_main` appears **0 times** in `b10903:common/arg.h` and the `#ifdef _WIN32` count-guarded `argv = utf8.ptrs.data()` override is still at `common/arg.cpp:1282`; **`0010`** — `b10903:tools/server/server-context.cpp:4554` still emits `{"vocab_type", meta.model_vocab_type}` uncast, so the `common_json` enum-to-bool trap is still live; **`0012`** — `b10903:src/llama-model.cpp:1491` still normalises with a bare `splits[i] /= split_sum;` and carries no `split_sum == 0` guard. All three line numbers are **identical to b10902**, which is what a byte-unchanged file looks like. Verified for real: `rm -rf build` then `cmake -B build -DBUILD_TESTING=ON` through the real `FetchContent` path, configure clean, stamp written at head `481c65f091f74c5e7089dd0a3a1cc6b50cced31e` (= `b10903`) with **all nine SHA-256 lines**; full `cmake --build --config Release` clean, zero errors; `ctest` **537/537**; wire-name extraction unchanged at **138 CLI / 57 request / 15 trainer** names (the configure-time `OAI_LAYER` reader sweep re-ran against b10903's sources). `nm -D` on the fresh `libjllama.so`: **40** `Java_*` exports, **0** C++-mangled ones. `mvn -pl llama clean test -Dtest=NativeLibraryLoadSmokeTest` **4/4, 0 skipped**, including `nativeBuildInfoMatchesPinnedVersionConstant` — run with `clean` because javac inlines `LLAMA_CPP_VERSION` into the test class and Maven's incremental compile cannot see that dependency. Full `mvn test`: **1755 run, 0 failures, 0 errors** (269 skipped — the model-gated classes, no GGUF in this sandbox). SpotBugs **0** findings; `spotless:check` clean; `javadoc:jar` BUILD SUCCESS. |

llama/CMakeLists.txt

@@ -173,7 +173,7 @@ set(LLAMA_BUILD_APP OFF CACHE BOOL "" FORCE)
 FetchContent_Declare(
 	llama.cpp
 	GIT_REPOSITORY https://github.com/ggerganov/llama.cpp.git
-	GIT_TAG        b10902
+	GIT_TAG        b10903
 	PATCH_COMMAND  ${CMAKE_COMMAND}
 		-DPATCH_DIR=${CMAKE_CURRENT_SOURCE_DIR}/patches
 		-DLLAMA_SRC=<SOURCE_DIR>

llama/src/main/java/net/ladenthin/llama/value/LlamaCppVersion.java

@@ -10,28 +10,28 @@
  * library was compiled against, exposed as a compile-time constant so callers can render a badge or
  * emit a startup log line without loading the native library.
  *
- * <p>{@link #LLAMA_CPP_VERSION} is a pure-Java string ({@code "b10902"}) that mirrors the
+ * <p>{@link #LLAMA_CPP_VERSION} is a pure-Java string ({@code "b10903"}) that mirrors the
  * {@code GIT_TAG} in {@code llama/CMakeLists.txt}. It is available even when {@code libjllama} is
  * absent (pure-Java checkout, before {@code System.load}), which is what makes it suitable for a
  * lightweight version badge in Android or other UIs.</p>
  *
  * <p>For the <em>authoritative</em> value that is baked into the native binary — the build number
- * plus the resolved upstream commit, e.g. {@code "b10902-<commit>"} — call
+ * plus the resolved upstream commit, e.g. {@code "b10903-<commit>"} — call
  * {@link net.ladenthin.llama.LlamaModel#getLlamaCppBuildInfo()} instead; that reads llama.cpp's own
  * {@code build-info} through JNI and therefore cannot drift from the compiled library (but requires
  * the native library to be loaded).</p>
  */
 public final class LlamaCppVersion {
 
     /**
-     * The pinned llama.cpp release tag this library was built against, e.g. {@code "b10902"}.
+     * The pinned llama.cpp release tag this library was built against, e.g. {@code "b10903"}.
      *
      * <p>Kept in lockstep with {@code GIT_TAG} in {@code llama/CMakeLists.txt} — see the
      * "Upgrading/Downgrading llama.cpp Version" checklist in {@code CLAUDE.md}. This is the
      * compile-time pin; use {@link net.ladenthin.llama.LlamaModel#getLlamaCppBuildInfo()} for the
      * value actually linked into the native binary.</p>
      */
-    public static final String LLAMA_CPP_VERSION = "b10902";
+    public static final String LLAMA_CPP_VERSION = "b10903";
 
     // Constants holder — not instantiable.
     private LlamaCppVersion() {}