feat: upgrade llama.cpp from b10909 to b10938

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: **b10909**
+Current llama.cpp pinned version: **b10938**
 
 ## 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 b10909 https://github.com/ggml-org/llama.cpp /tmp/lc
+git clone --depth 1 --branch b10938 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 b10909`), the
+Because `sccache` is **content-addressed** and llama.cpp is pinned (`GIT_TAG b10938`), 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
@@ -1536,7 +1536,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 b10909`.
+llama.cpp is fetched via CMake FetchContent, pinned to `GIT_TAG b10938`.
 
 **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 b10909](https://img.shields.io/badge/llama.cpp-%23b10909-informational)](https://github.com/ggml-org/llama.cpp/releases/tag/b10909)  
+[![llama.cpp b10938](https://img.shields.io/badge/llama.cpp-%23b10938-informational)](https://github.com/ggml-org/llama.cpp/releases/tag/b10938)  
 [![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

@@ -714,3 +714,15 @@ Used during `llama.cpp` version bumps: when upgrading, scan this file from the r
 | b10905–b10908 | patches + upstream verification | This is the **first chunk** of a chunked bump: `git diff b10905 b10909` is **149 KiB**, over the runbook's 100 KiB threshold, so `.github/scripts/llama-next-version.sh` selected b10908 as the largest intermediate tag under it. All ten patches were applied in filename order to a pristine b10909 worktree (the chunk target's successor, i.e. the strictest case) and **all ten applied cleanly**, `0012` included — worth stating explicitly because chunk 2 edits `tests/CMakeLists.txt`, which `0012` also patches, and the two hunks turned out not to collide. |
 | b10908–b10909 | One commit — **#28164**, "metal : single-source fusion table + fusion debug rework": `ggml/src/ggml-metal/*` (a new `ggml-metal-fusion.{cpp,h}` pair, 606 lines, plus reworked `ggml-metal-ops.cpp`), `src/llama-context.cpp` (2 lines), `src/models/{minimax-01,plamo2,qwen3vl}.cpp`, and test scaffolding (`tests/test-fusion.cpp`, `tests/fusion/MTL.csv`, `tests/test-backend-ops.cpp`, `tests/CMakeLists.txt`, `.github/workflows/fusion.yml`, `ci/run.sh`). 26 files, 1794 insertions, 235 deletions, **111 KiB**. | **Zero files on the priority-ordered API-compatibility list, despite being the larger of the two chunks.** The whole change is inside the Metal backend plus upstream's own test/CI scaffolding; none of `common/`, `include/`, `tools/server/` or `tools/mtmd/` is touched, so every row of that table has no input. The `tests/*` files are **applied but never compiled** here — a FetchContent subproject builds with `LLAMA_BUILD_TESTS=OFF` — which is the same reason `0001`'s and `0012`'s upstream tests are inert in this repo. The real gate for this chunk is the three macOS arm64 jobs, where the reworked Metal fusion path is actually compiled and run. |
 | b10908–b10909 | patches + upstream verification | **All ten patches apply at pristine b10909, and all four standing drop-checks say "still required"** — run against the pristine tag rather than inferred, because the fail-loud applier detects "does not apply" but never "upstream already fixed this": `0001` (`common_params_parse_main` 0 occurrences in `common/arg.h`; the WIN32 `argv = utf8.ptrs.data()` override still at `common/arg.cpp:1282`), `0010` (`{"vocab_type", meta.model_vocab_type}` still uncast at `server-context.cpp:4554`), `0012` (bare `splits[i] /= split_sum;` still at `src/llama-model.cpp:1491`), `0013` (the three s390x helpers still unguarded at lines 73/77/83, between the guard blocks at 28 and 100). **On `0013` specifically:** it was filed upstream during this bump as [ggml-org/llama.cpp#28775](https://github.com/ggml-org/llama.cpp/pull/28775) ("ggml-cpu(s390x): guard VXE-only repack helpers"), approved by the s390x maintainer and open at the time of writing. When it merges, the first tag carrying it will make the applier abort the configure on every platform — that is the designed signal, and the response is to **delete** `0013`, not refresh it (see the `0009` precedent at b10280). **`0012`'s `tests/CMakeLists.txt` hunk was checked against this chunk's edit to the same file and does not collide.** |
+| b10909–b10919 | 10 commits, **93 KiB**. Project-relevant: `tools/server/server-models.{cpp,h}` + new `server-common.{cpp,h}` content (**#28555**, "server: refactor subproc handling"), `common/speculative.cpp` (a comment typo, **#28750**), and **build-system** changes — `common/CMakeLists.txt`, `tools/server/CMakeLists.txt`, `tools/mtmd/CMakeLists.txt` gain PCH + unity build (**#28091**), with **#28763** disabling the llama-server PCH under MSVC. | **`server-models.cpp` is `patches/0008`'s target and it moved the most in this whole range** (+277/−200 across b10909–b10938, most of it here). The patch still applies — verified against pristine b10938, not assumed. The PCH/unity-build change is the class `CLAUDE.md` warns a header diff cannot catch, but it is confined to upstream's *own* target definitions: this project adds the upstream server `.cpp` files to **its own** `jllama` target rather than linking upstream's, so their `target_precompile_headers` does not reach us; `llama-common` is linked as a library, where PCH is an internal build detail. |
+| b10909–b10919 | patches + upstream verification | First chunk of a **six-chunk** bump: `git diff b10909 b10938` is **1003 KiB**, ten times the runbook's 100 KiB threshold. All ten patches were applied in filename order to a pristine **b10938** worktree up front — the strictest case, and the one that matters when a patch target churns like `server-models.cpp` does here — and **all ten applied cleanly**. |
+| b10919–b10920 | One commit — **#28589**, "hexagon: support for multi-device model split (aka row-split)": 45 files, 4345 insertions, 1948 deletions, **541 KiB**. Entirely `ggml/src/ggml-hexagon/**` plus `scripts/snapdragon/**`. | **The largest single chunk in this bump and a completely empty review surface.** It is over the threshold and cannot be subdivided — it is one commit — but the size is irrelevant here: **zero** files under `common/`, `include/`, `src/`, `tools/` or `vendor/`, so no patch target, no priority-list row, and no compiled translation unit of this project is touched. The Hexagon backend is not among the backends this project builds (no `GGML_HEXAGON` job exists in `publish.yml`), so the code is not even compiled. |
+| b10919–b10920 | patches + upstream verification | Nothing to verify beyond the up-front b10938 application: this chunk's file set and `patches/`' file set are disjoint by inspection of the full `git diff --name-only`, not by aggregate reasoning. |
+| b10920–b10927 | 7 commits, **94 KiB**. Project-relevant: **`vendor/cpp-httplib/httplib.{cpp,h}` updated to 0.56.0** (**#28787**, +296/−92 across the two files) and `tools/server/server-models.cpp` again (**#28747**, the router child-state command is now framed as a whole line). The rest is OpenCL/WebGPU/SYCL/RPC backend work. | **`httplib.cpp` is compiled directly into `libjllama`**, so a vendored-library bump here is a real translation unit for this project, not upstream's business — it is the 16.6k-line file the CI cache notes single out as a build-time cost. It is consumed only through `<cpp-httplib/httplib.h>` by upstream's `server-http.cpp`; this project's own C++ never includes it, so the exposure is confined to whether it still compiles and links, which the build proves. No SSL is configured (`CPPHTTPLIB_OPENSSL_SUPPORT` left undefined), so the 0.56.0 TLS surface is not reached. |
+| b10920–b10927 | patches + upstream verification | `server-models.cpp` moves again (`patches/0008`), and again the patch applies at pristine b10938. Nothing else in the chunk is a patch target. |
+| b10927–b10933 | 6 commits, **41 KiB** — the smallest chunk. Project-relevant: `tools/server/server-common.cpp` + `server-models.cpp` (**#28530**, model downloads at the model limit; **#28795**, missing headers) and `common/jinja/runtime.cpp` (**#28817**, dot-property integer literals in Jinja). The rest is CUDA/HIP tuning, a WebUI cache and a clang PCH timestamp fix. | Nothing on the priority-ordered API-compatibility list. `common/jinja/runtime.cpp` is compiled into `llama-common`, which this project links, but the change is internal to Jinja template evaluation and alters no signature this project calls. The `server-*.cpp` edits are in upstream translation units this project compiles, so they are covered by the build rather than by a header review. |
+| b10927–b10933 | patches + upstream verification | `server-models.cpp` touched a third time (`patches/0008`); applies at pristine b10938. No other patch target in the chunk. |
+| b10933–b10934 | One commit — **#28736**, "common : implement common_schema internal representation for JSON schemas": 45 files, 1733 insertions, 1928 deletions, **215 KiB**. Replaces raw `common_json` schema handling with a typed `common_chat_schema` tree: new `common/json-schema.{h,cpp}`, a restructured `common/parsers/**` (16 model-specific parsers), and edits to `common/chat.{h,cpp}`, `common/peg-parser.{cpp,h}`, `common/json-schema-to-grammar.{h,cpp}`, `common/arg.cpp`, `tests/CMakeLists.txt`, `tools/server/server-{common,schema}.cpp`. | **The one chunk in this bump with real exposure — three patch targets and two priority rows in a single commit — and it lands clean, for reasons worth recording rather than re-deriving.** (1) `common/chat.h` (priority row 2) is **purely additive**: one new declaration, `common_chat_tool_parameters(const common_json &)`; no existing signature moved. (2) `common/peg-parser.cpp` is `patches/0011`'s file, but every edit is in the **schema** machinery — `dump_impl`'s `Schema(...)` rendering, `common_peg_parser_builder::schema`, and `build_grammar`'s `schema_delegates` lambda (which collapses ~25 lines of raw-JSON type sniffing into `s.raw && s.node->may_be_string()`). `0011` modifies the **until-parser's UTF-8 `INVALID` branch**, a disjoint region that survives intact — the paired `is_lenient()`/`INVALID` structure is still at lines 482/487 and 521/527 of the pristine b10938 file. (3) `common/json-schema-to-grammar.h` is on the *safe-to-skip* list (not used directly by project code). (4) The **wire surface did not move**, checked mechanically rather than by reading: `server-schema.cpp`'s field set is **68 → 68 identical**, `server-task.cpp`'s response keys **142 → 142 identical**, and `repeat_last_n`/`dry_penalty_last_n` keep `set_hard_limits(0, INT32_MAX)`. The new `common/json-schema.{h,cpp}` and `common/parsers/**` sources join `common/CMakeLists.txt`, i.e. the `llama-common` library this project links — this project's `CMakeLists.txt` never enumerates `common/` sources, so they are picked up with no project-side change. |
+| b10933–b10934 | patches + upstream verification | Three patch targets in one commit (`common/peg-parser.cpp` → `0011`, `common/arg.cpp` → `0001`, `tests/CMakeLists.txt` → `0012`) and **all three still apply at pristine b10938**, along with the other seven. This is the chunk that justified applying the whole patch set against the *target* tag up front rather than chunk by chunk. |
+| b10934–b10938 | 4 commits, **18 KiB** — the final chunk, reaching the latest upstream release. `common/log.{cpp,h}` + `common/arg.cpp` + `common/fit.cpp` (**#28586**, a new `LOG_JSON` macro for structured logging), `common/parsers/qwen3-coder.cpp` (**#28742**), plus OpenCL and Vulkan backend fixes. | **Additive only on the one row that matters.** `common/log.h` is on the *safe-to-skip* list, and the change adds a macro rather than altering an existing one; this project does not use upstream's logging macros — it has its own `log_helpers.hpp` with an independent `nlohmann::json` alias that never touches the server's `json`. `common/arg.cpp` is `patches/0001`'s file and is touched for the third time in this range; the patch applies. |
+| b10934–b10938 | patches + upstream verification | End of the six-chunk walk. **All ten patches apply at pristine b10938 and all four standing drop-checks say "still required"**, 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` 0 occurrences in `common/arg.h`; the WIN32 override still at `common/arg.cpp:1282` — unmoved despite three edits to that file in this range), `0010` (`{"vocab_type", …}` still uncast at `server-context.cpp:4554`), `0012` (bare `splits[i] /= split_sum;` still at `src/llama-model.cpp:1491`), `0013` (the three s390x helpers still unguarded at 73/77/83). **`0013` remains filed-but-unmerged upstream** as [ggml-org/llama.cpp#28775](https://github.com/ggml-org/llama.cpp/pull/28775); when it merges, the first tag carrying it aborts the configure and the response is to **delete** the patch, not refresh it. |

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        b10909
+	GIT_TAG        b10938
 	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 "b10909"}) that mirrors the
+ * <p>{@link #LLAMA_CPP_VERSION} is a pure-Java string ({@code "b10938"}) 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 "b10909-<commit>"} — call
+ * plus the resolved upstream commit, e.g. {@code "b10938-<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 "b10909"}.
+     * The pinned llama.cpp release tag this library was built against, e.g. {@code "b10938"}.
      *
      * <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 = "b10909";
+    public static final String LLAMA_CPP_VERSION = "b10938";
 
     // Constants holder — not instantiable.
     private LlamaCppVersion() {}