feat!: upgrade llama.cpp from b10817 to b10819

CHANGELOG.md

@@ -58,7 +58,7 @@ from version 5.0.0 onward. Pre-fork releases (`1.x`–`4.2.0`) were authored by
   where the backend cannot provide it, `OFF` disables it.
 
 ### Changed
-- **llama.cpp `b10731` → `b10817`.** No project-source change: every header move in the range is
+- **llama.cpp `b10731` → `b10819`.** No project-source change: every header move in the range is
   additive or a **widening** const-qualification, and the server wire contract is byte-identical
   (request-field set, `set_hard_limits` bounds and response keys all verified mechanically, which is
   the check that catches the contract-behind-a-stable-signature breaks a header diff cannot see).
@@ -105,6 +105,11 @@ from version 5.0.0 onward. Pre-fork releases (`1.x`–`4.2.0`) were authored by
   - The remaining three are upstream's own version bump, a `LLAMA_VERSION_MINOR` change and a
     BoringSSL pin that only applies with `LLAMA_BUILD_BORINGSSL`, which this project leaves off.
 
+  The final `b10817` → `b10819` step is two commits over three files, none of which this project
+  links against: a **Metal memory-leak fix** on an early-return path
+  (`ggml-metal-context.m`, llama.cpp #28399), a SYCL Kronecker-product/FWHT restore (#28254) and
+  the matching upstream test. Nothing in the review surface, nothing in the server contract.
+
 - **llama.cpp `b10682` → `b10731`.** One project-source change came out of it, and it is the kind a
   header diff does not surface: upstream renamed `--tensor-read-lazy` to `-lzm` / `--lazy-mode`
   (env `LLAMA_ARG_TENSOR_READ_LAZY` → `LLAMA_ARG_LAZY_MODE`) **with no alias**. The binding emitted

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: **b10817**
+Current llama.cpp pinned version: **b10819**
 
 ## Upgrading CUDA Version
 
@@ -490,7 +490,7 @@ needs no extra step here, `build-webui` re-reads the tag and rebuilds the matchi
 ships no UI):
 ```bash
 # needs node/npm + network; embed.cpp is plain C++17 (no npm)
-git clone --depth 1 --branch b10817 https://github.com/ggml-org/llama.cpp /tmp/lc
+git clone --depth 1 --branch b10819 https://github.com/ggml-org/llama.cpp /tmp/lc
 ( cd /tmp/lc/tools/ui && npm ci && npm run build \
   && ( cd dist && find . -type f -not -path './_gzip/*' \
        | while read -r f; do mkdir -p "_gzip/$(dirname "$f")"; gzip -9 -c "$f" > "_gzip/$f"; done ) \
@@ -530,7 +530,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 b10817`), the
+Because `sccache` is **content-addressed** and llama.cpp is pinned (`GIT_TAG b10819`), 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
@@ -1451,7 +1451,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 b10817`.
+llama.cpp is fetched via CMake FetchContent, pinned to `GIT_TAG b10819`.
 
 **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 b10817](https://img.shields.io/badge/llama.cpp-%23b10817-informational)](https://github.com/ggml-org/llama.cpp/releases/tag/b10817)  
+[![llama.cpp b10819](https://img.shields.io/badge/llama.cpp-%23b10819-informational)](https://github.com/ggml-org/llama.cpp/releases/tag/b10819)  
 [![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

@@ -692,3 +692,5 @@ Used during `llama.cpp` version bumps: when upgrading, scan this file from the r
 | b10792–b10797 | patches + upstream verification | **Zero intersection with the patch set, established mechanically.** The 42 files the eight patches touch were intersected against the range's 18 changed files: empty, so no patch context can have moved. Confirmed by running the applier for real anyway: fresh `rm -rf build && cmake -B build -DBUILD_TESTING=ON`, configure clean, stamp at `head 832fd6f1741ad9f66fb2a785002396700666595a`, all eight hashes recorded. **This step needed no chunking decision**: the full `b10792...b10797` diff is 46 KB across 5 commits, comfortably inside the runbook's 100 KiB threshold, so it is a straight bump by the rule rather than in spite of it. |
 | b10797–b10817 | `common/build-info.{h,cpp.in}` (**#28322: `llama_print_build_info` gains a `FILE *` stream**), `ggml/include/ggml-backend.h` (**REMOVES `ggml_backend_op_alloc_size_may_expand`**, via the #28379 ggml sync), `tools/mtmd/mtmd.cpp` + `clip.cpp` (**#28335: gemma4 vision handling; image-token limit 40/280 → 70/1120**), `CMakeLists.txt` (`LLAMA_VERSION_MINOR` 3 → 4, #28386), `vendor/cpp-httplib/CMakeLists.txt` (BoringSSL pin, #28354). Everything else in the range is GPU-backend work (`ggml-opencl` +940 and a new 871-line Adreno SDPA kernel, Metal fa-vec tunings for M3/M3 Max, SYCL memtrace), a new model architecture (`src/models/hy-v4.cpp`, #28127), upstream CI and the WebUI. | **No project-source change.** The whole review surface is **7 files, +12 / −13**. Two entries needed checking rather than skimming. **(1)** `llama_print_build_info(const char *)` became `llama_print_build_info(const char *, FILE * = stderr)` — a **default argument**, so any existing one-argument call still compiles; the project does not call it at all and reads `llama_build_info()`, which is untouched. Worth noting anyway because `build-info` is what `NativeLibraryLoadSmokeTest` cross-checks against the pin, and this is the second consecutive range to move that file (b10792–b10797 carried #28278). **(2)** the **removal** of `ggml_backend_op_alloc_size_may_expand` from a public ggml header — a deletion is the one shape that breaks a build with no diff hunk to notice, so the project source was grepped for it: zero references, in `src/main/cpp` and `src/test/cpp` alike. The server contract was re-checked and is byte-identical (request fields, `set_hard_limits` bounds, response keys in both emit forms); `tools/server/` has no `.cpp`/`.h` change in the range at all. |
 | b10797–b10817 | patches + upstream verification | **Zero intersection with the patch set.** The 42 files the eight patches touch were intersected against the range's changed-file list: empty, so no patch context can have moved. The applier was run for real anyway — fresh `rm -rf build && cmake -B build -DBUILD_TESTING=ON`, configure clean, stamp at `head cd8cdf397dc21d986e69069ce2180651d693fdff`, all eight hashes recorded. **Chunking:** the full diff is 307 KB, over the runbook's 100 KiB threshold, but excluding `ggml/src/**`, `tools/ui/**`, `docs/**`, `.github/**` and `conversion/**` — every one of them outside the review surface the rule exists to bound — it is **68 KB, under the threshold**. Same call as the previous bump, and this time the excluded-diff figure alone justifies it. **This range does NOT address the macOS-15 regression introduced at b10797** (see the two rows above): `src/llama-model-loader.cpp` is untouched here and `hparams.n_expert_used_max()` — the prime suspect from #28323 — is still called at both b10797 sites. Expect `Java Tests macOS 15 arm64` to stay red until that is bisected. |
+| b10817–b10819 | `ggml/src/ggml-metal/ggml-metal-context.m` (**#28399: one-line memory-leak fix on an early-return path**), `ggml/src/ggml-sycl/fwht.cpp` (#28254: restore Kronecker-product FWHT support and unbreak `test-backend-ops` on SYCL), `tests/test-backend-ops.cpp`. | **No project-source change, and the review surface is empty**: all three changed files are ggml backends or upstream tests, none of which this project links against or compiles into `jllama`. The server contract was re-checked and is byte-identical (request-field set, response keys in both emit forms); `tools/server/`, `common/`, `include/`, `tools/mtmd/` and `ggml/include/` have no change at all in the range. The Metal leak fix is worth a note next to the **macOS-15 regression** tracked from b10797: that job logs `ggml_metal_log_allocated_size: warning: current allocated size is greater than the recommended max working set size`, so a leaked Metal object on an early return is at least adjacent to the symptom. It is **not** a fix for it — the observed failure is a libc++ `"vector"` exception thrown ~30 ms into `llama_model_load` of the draft model, before any allocation of that kind, and the no-Metal macOS job fails identically. Treat it as one variable removed, not as the answer. |
+| b10817–b10819 | patches + upstream verification | **Zero intersection with the patch set**: the 42 files the eight patches touch versus the range's 3 changed files — empty, so no patch context can have moved. The applier was run for real regardless: fresh `rm -rf build && cmake -B build -DBUILD_TESTING=ON`, configure clean, stamp at `head 6a1a922d269908a29cbd4b49c27e6a8e7fd10fae`, all eight hashes recorded. **No chunking question arises**: the full diff is 17 KB across 2 commits, far inside the runbook's 100 KiB threshold, so this is a straight bump *by* the rule rather than an exception to 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        b10817
+	GIT_TAG        b10819
 	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 "b10817"}) that mirrors the
+ * <p>{@link #LLAMA_CPP_VERSION} is a pure-Java string ({@code "b10819"}) 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 "b10817-<commit>"} — call
+ * plus the resolved upstream commit, e.g. {@code "b10819-<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 "b10817"}.
+     * The pinned llama.cpp release tag this library was built against, e.g. {@code "b10819"}.
      *
      * <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 = "b10817";
+    public static final String LLAMA_CPP_VERSION = "b10819";
 
     // Constants holder — not instantiable.
     private LlamaCppVersion() {}