VoxelBench 2.3.0

Check your Java command line, and auto-bench runs that survive a lost connection

VoxelBench 2.3.0 checks your server's Java command line against your Java version and your memory, warns at startup when the heap can fill the container, and masks the private parts of that line in your reports. Auto-bench runs started from voxelbench.com no longer fail when the bot's connection drops in the middle of a run.

/bench jvm: your Java command line, checked

Java options come and go between Java versions, and a line copied from an old guide can carry options that are obsolete, that belong to another garbage collector, or that stop the JVM from starting at all. /bench jvm asks voxelbench.com's optimiser, which knows, for your Java version:

• which options were removed (the JVM refuses to start), are obsolete (ignored) or deprecated;
• which need an unlock option (-XX:+UnlockExperimentalVMOptions) to be accepted;
• which garbage collectors conflict, and which options belong to a collector you do not use;
• how much heap fits: in a container, the memory outside the heap (metaspace, compiled code, thread stacks, network buffers) needs room too.

You get the corrections by severity, then a corrected command line: your current line with those corrections only, so it cannot be worse than the one you run. Click it in game to copy it; it is also written to plugins/VoxelBench/jvm-flags.txt. Paste it into your host's startup command or your start script, keep your own jar name, and restart.

Below it, options worth testing — Aikar's G1 settings, generational ZGC from Java 21 — with their source. They are never applied for you: run a benchmark before and after, and keep what measures better.

Only the -X and -XX options are sent, without the file paths some of them carry, with your Java version, the heap and memory limits, the number of processors and the server type and version. -D properties, agents and paths stay on your machine: the corrected line is assembled there. The command needs the voxelbench.jvm permission (operators by default).

For example, -Xms6500M -Xmx8192M in a container limited to 8,203 MiB leaves 11 MiB for everything outside the heap. The corrected line uses -Xmx6972M, which keeps 1,231 MiB outside it (1 GiB or 15 % of the limit, whichever is larger).

A warning at startup when the heap can fill the container

When the heap may grow so close to the container's memory limit (or the machine's, without a container) that less than 512 MiB, or 5 % of that limit, is left for the rest, the server can be killed for lack of memory without a word in its console. VoxelBench now says so once at startup and points to /bench jvm.

Java flags in reports are masked

A Java command line often holds secrets — a license key in a -D property, a database password, the path of an agent in a user's home folder — and a report can be public. Reports now replace with <redacted> the values of -D properties (except a few harmless ones such as file.encoding), agent paths, and the file paths carried by some -X/-XX options, at every anonymization level. The options themselves are unchanged. voxelbench.com masks the lines of older reports the same way when it shows them.

Reports also carry the Java distribution (vendor and VM name): on OpenJ9, HotSpot options mean nothing.

Auto-bench runs survive a lost connection

On some hosts, a long server freeze is followed by the bot's connection being closed by the host's network, and the job was marked as failed while the run went on alone. Now:

• The run keeps what it says to the bot while the bot is away.
• The bot comes back and proves it is the same bot with a single-use token voxelbench.com gave it for this job (five per job, so up to five reconnections). It then receives everything it missed, in order, and the run goes on.
• Before a test that needs a player, VoxelBench waits up to 5 minutes for such a bot, instead of 30 seconds.

The bot's name is not enough. On an offline-mode server anyone can log in under the bot's name. Without the token, that player receives nothing from the run, does not count as the bot, and gets the game mode the bot had before the run — never spectator.

The bot is no longer saved in spectator mode. It was put in spectator mode for its run and kept it on disk, so whoever logged in next under its name was a spectator. It now gets its game mode back when it leaves (on Folia, at its next login).

Upgrade

Drop the new jar in plugins/ and restart. No config or data migration. New permission voxelbench.jvm (operators by default). /bench jvm writes plugins/VoxelBench/jvm-flags.txt.