Memory

ac-cli/src/main/resources/agenticcode.properties

@@ -4,4 +4,4 @@
 server.url=http://localhost:8787
 # Stamped by manage-ac.sh (stamp_cli_version) from ac-code-server's agenticcode.version
 # at build time. "dev" means this jar wasn't built via manage-ac.sh.
-version=156
+version=157

ac-code-server/src/main/docker/Dockerfile.jvm

@@ -12,5 +12,9 @@ COPY target/quarkus-app/quarkus/ /work/quarkus/
 
 EXPOSE 8787
 
-ENV JAVA_OPTS="-Djava.util.logging.manager=org.jboss.logmanager.LogManager"
+# JVM options are NOT set here. A `ENV JAVA_OPTS=...` used to sit at this spot and had no effect
+# whatsoever: the exec-form ENTRYPOINT below runs `java` directly, with no shell to expand the
+# variable, and the JVM itself only honours JDK_JAVA_OPTIONS / JAVA_TOOL_OPTIONS. Options now live
+# in docker-compose.yml under JDK_JAVA_OPTIONS (heap cap + log manager) — keep them in one place,
+# because a value set in compose replaces an image-level one rather than appending to it.
 ENTRYPOINT ["java", "-jar", "/work/quarkus-run.jar"]

ac-code-server/src/main/resources/application.properties

@@ -3,7 +3,7 @@ quarkus.http.port=8787
 # AgenticCode's own release counter (not the Maven project version) — bump this by hand for each
 # release. Single source of truth for the startup log line, GET /api/version, and the OpenAPI
 # info version (referenced below via property expression, not duplicated).
-agenticcode.version=156
+agenticcode.version=157
 # OpenAPI / Swagger UI (item 48) — the generated spec is the contract the web-UI TS client
 # is generated against. Served at /q/openapi (yaml/json); Swagger UI at /q/swagger-ui in dev.
 mp.openapi.extensions.smallrye.info.title=AgenticCode API

docker-compose.yml

@@ -7,6 +7,19 @@ services:
       - "7687:7687"
     environment:
       NEO4J_AUTH: neo4j/agenticcode
+      # Memory caps. Without them the JVM sizes its heap ergonomically at 25% of host RAM
+      # (~7.8 GiB here) and never gives it back: measured 6.17 GiB still held one hour after a
+      # deep refresh of upms had finished, at <1% CPU. The cap is what forces the JVM to
+      # collect rather than commit.
+      NEO4J_server_memory_heap_max__size: "2G"
+      NEO4J_server_memory_heap_initial__size: "512M"
+      # Deliberately raised 512M -> 1G alongside the smaller heap: the store is 2.0 GB, so a
+      # bigger page cache offsets the tighter heap instead of pushing the load onto disk.
+      NEO4J_server_memory_pagecache_size: "1G"
+    # Hard ceiling: heap 2G + pagecache 1G + ~1G for metaspace, direct buffers and GC overhead.
+    # Deliberately not tighter — an OOM-kill mid-refresh would leave the graph half-updated, which
+    # is far worse than a GB of headroom. Still well under the 6.17 GiB measured without a cap.
+    mem_limit: 4g
     volumes:
       - neo4j-data:/data
     healthcheck:
@@ -27,6 +40,18 @@ services:
       NEO4J_URI: bolt://neo4j:7687
       NEO4J_USER: neo4j
       NEO4J_PASSWORD: agenticcode
+      # JDK_JAVA_OPTIONS (not JAVA_OPTS) — the entrypoint is `java -jar`, which expands no shell
+      # variable; the JVM reads this one by itself. Both settings must live here: a value set in
+      # compose replaces the image's, it does not append, so the log-manager property would be
+      # silently dropped if it were left in the Dockerfile.
+      #
+      # -Xmx3g against a measured heap peak of 2772 MB during the upms deep refresh (45 finalize
+      # samples, never above 3 GB). Ergonomics would otherwise allow 7956 MB and the process kept
+      # 4.91 GiB resident an hour after the refresh ended.
+      JDK_JAVA_OPTIONS: "-Xmx3g -Djava.util.logging.manager=org.jboss.logmanager.LogManager"
+    # Heap 3G + metaspace/code cache/direct buffers. Peak RSS measured during the refresh was 5.0 GB
+    # with an uncapped heap; with -Xmx3g this ceiling leaves room without allowing that again.
+    mem_limit: 4g
     volumes:
       # Mounted at the same absolute host path so project roots registered via
       # the API (which store absolute host paths) resolve inside the container too.