From 77dcd2d89f67fd7f250c2714339e9e5094ddf39f Mon Sep 17 00:00:00 2001 From: Claude Date: Sat, 5 Sep 2026 18:20:38 +0000 Subject: [PATCH] feat!: upgrade llama.cpp from b10817 to b10819 No project-source change, and this time the review surface is empty rather than merely small: the range is 2 commits over 3 files, all of them ggml backends or upstream tests, none of which this project links against or compiles into jllama. Nothing under common/, include/, tools/server/, tools/mtmd/ or ggml/include/ moved at all. The server contract was re-checked anyway and is byte-identical (request-field set, response keys in both emit forms). * #28399 metal : one-line memory-leak fix on an early-return path * #28254 sycl : restore Kronecker-product FWHT support, unbreak test-backend-ops on SYCL The Metal leak fix deserves a note next to the macOS-15 regression tracked from b10797, because it is adjacent to the symptom without being the cause: that job logs "current allocated size is greater than the recommended max working set size", so a leaked Metal object on an early return is the right neighbourhood. It is NOT a fix. The observed failure is a libc++ "vector" exception thrown ~30 ms into llama_model_load of the draft model, before allocation of that kind, and the no-Metal macOS job fails identically. One variable removed, not the answer -- expect `Java Tests macOS 15 arm64` to stay red until that is bisected. Patches: zero intersection with the 42 files the eight patches touch, so no context can have moved. The applier was run for real regardless -- fresh build dir, configure clean, stamp at head 6a1a922d, 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. Verified locally: fresh configure clean, full build with zero warnings on the project TUs, ctest 520/520, mvn clean verify 1742 Java tests green (including NativeLibraryLoadSmokeTest, which cross-checks LLAMA_CPP_VERSION against the linked build-info), bytecode gate clean over llama/target. Co-Authored-By: Claude Opus 5 Claude-Session: https://claude.ai/code/session_01AnNYn8W1xuVxVJtyL34GyH --- CHANGELOG.md | 7 ++++++- CLAUDE.md | 8 ++++---- README.md | 2 +- docs/history/llama-cpp-breaking-changes.md | 2 ++ llama/CMakeLists.txt | 2 +- .../java/net/ladenthin/llama/value/LlamaCppVersion.java | 8 ++++---- 6 files changed, 18 insertions(+), 11 deletions(-) diff --git a/CHANGELOG.md b/CHANGELOG.md index c1f0382e..175a4176 100644 --- a/CHANGELOG.md +++ b/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 diff --git a/CLAUDE.md b/CLAUDE.md index e78d8186..f05d0285 100644 --- a/CLAUDE.md +++ b/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` 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 diff --git a/README.md b/README.md index 1527ba8b..66919da3 100644 --- a/README.md +++ b/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) diff --git a/docs/history/llama-cpp-breaking-changes.md b/docs/history/llama-cpp-breaking-changes.md index c294f5e7..809c1a20 100644 --- a/docs/history/llama-cpp-breaking-changes.md +++ b/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. | diff --git a/llama/CMakeLists.txt b/llama/CMakeLists.txt index d01e3355..523e64f2 100644 --- a/llama/CMakeLists.txt +++ b/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= diff --git a/llama/src/main/java/net/ladenthin/llama/value/LlamaCppVersion.java b/llama/src/main/java/net/ladenthin/llama/value/LlamaCppVersion.java index 478c604a..43346887 100644 --- a/llama/src/main/java/net/ladenthin/llama/value/LlamaCppVersion.java +++ b/llama/src/main/java/net/ladenthin/llama/value/LlamaCppVersion.java @@ -10,13 +10,13 @@ * 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. * - *

{@link #LLAMA_CPP_VERSION} is a pure-Java string ({@code "b10817"}) that mirrors the + *

{@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.

* *

For the authoritative value that is baked into the native binary — the build number - * plus the resolved upstream commit, e.g. {@code "b10817-"} — call + * plus the resolved upstream commit, e.g. {@code "b10819-"} — 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).

@@ -24,14 +24,14 @@ 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"}. * *

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.

*/ - public static final String LLAMA_CPP_VERSION = "b10817"; + public static final String LLAMA_CPP_VERSION = "b10819"; // Constants holder — not instantiable. private LlamaCppVersion() {}