How to Configure the JVM Heap Size (-Xmx) for "Java and Kotlin by IntelliJ IDEA" extension in VS Code

Problem

You want to control how much memory the "Java and Kotlin by IntelliJ IDEA" extension for VS Code uses, or you noticed it holding around 2 GB of RAM on a small project (for example, a freshly created "Hello World" Kotlin project) without any edits or extra configuration.

Cause

The extension runs an IntelliJ-based backend in its own JVM, and that JVM starts with a default maximum heap of 2 GB. The default targets medium-sized projects, so it looks oversized next to a trivial project — but it is a ceiling, not a reservation.

Resolution

Set the maximum heap explicitly through the extension's JVM arguments in the VS Code settings file (settings.json):

"intellij.additionalJvmArgs": [
    "-Xmx500m",
],

Reload the VS Code window for the new value to apply.

Use a suffix to pick the unit: -Xmx500m for 500 MB, -Xmx2g for 2 GB. Rough starting points: 500 MB – 1 GB for a small single-module project, the 2 GB default for a typical project, 3 – 4 GB or more for a large multi-module codebase or one with heavy Gradle/Maven models.

Understanding what -Xmx actually controls

-Xmx sets the upper limit of the Java heap. It does not pre-allocate that memory, and it is not the total memory of the process.

Heap usage grows on demand. The JVM asks the OS for memory as objects are allocated and returns little of it afterwards, so on a long session the resident size drifts up toward the ceiling and stays there. That is normal — the garbage collector is not obliged to run just because memory is free to take. A larger -Xmx therefore means fewer GC cycles and a larger steady-state footprint; a smaller one means a smaller footprint and more frequent GC.

Process RAM is always larger than the heap. On top of the heap the JVM needs metaspace (loaded classes), JIT-compiled code cache, per-thread stacks, GC bookkeeping, and native/off-heap buffers such as memory-mapped indexes. Expect the process to sit a few hundred MB above whatever the heap is using, so a 500 MB heap does not produce a 500 MB process.

Setting -Xmx too low is worse than leaving it high. When the live set does not fit, the JVM spends its time collecting instead of working: indexing and code analysis slow down, freezes appear, and eventually the backend fails with java.lang.OutOfMemoryError: Java heap space. Lower the value only if the project is genuinely small, and raise it again at the first sign of sluggishness or an OOM error.

Tune only when there is a reason. Reduce it when the machine is memory-constrained or the project is trivial; increase it when working with a large codebase. Otherwise the default is a reasonable trade-off between footprint and responsiveness.