About JVM Scope

JVM Scope is a technical publication about Java, the JVM, and the ecosystem built on top of them. Every article starts from the same question:

What is the system actually doing beneath the abstraction?

Why this publication exists

Frameworks, standard-library types and runtime flags all present a simple surface. That surface holds right up to the moment behaviour stops matching the mental model — a latency spike with no obvious cause, a thread pool that will not scale, a startup profile that quietly doubled after a dependency bump. At that point the documentation runs out, because a framework’s documentation describes its API and not the runtime underneath it. This site is written for the gap between those two things.

The aim is narrow and deliberate: explain the mechanism, in enough detail that a reader can go and observe it on their own machine. That means naming the flag, naming the JDK class, stating the release the behaviour was seen on, and describing a measurement precisely enough to repeat. It also means being willing to end on “it depends” when the honest answer depends on the workload, and then saying what it depends on and how to measure it. The readership assumed throughout is working JVM developers with a few years behind them — people who already ship Java and have hit the point where the surface stopped explaining what they were seeing.

Advice ages with the JDK; mechanisms age far more slowly. A tuning recommendation written for JDK 8 is mostly archaeology now, while an explanation of how escape analysis decides to scalar-replace an object still holds. Preferring the second over the first is the long-term bet this publication makes, and it is why articles are written to be re-readable against a newer release rather than to be correct for one afternoon.

Who writes it

Marcus Venn writes every article here. His work covers runtime behaviour — compilation tiers, deoptimisation, escape analysis, the distance between what the bytecode says and what the CPU executes; concurrency — platform and virtual threads, locks, memory visibility, and the failure modes that only surface under contention; memory and garbage collection — collector trade-offs, allocation profiles, and what pause-time numbers do and do not tell you; frameworks such as Spring and the Jakarta stack, measured at the runtime level rather than described at the API level; and diagnostics — thread dumps, JFR recordings and GC logs, read directly rather than pattern-matched against folklore.

The method behind that range matters more than the range itself. Claims are settled against JDK source, a flag’s documented behaviour, or an experiment that states its JDK build and its hardware — and where a result is a property of one specific build, the article says so rather than generalising. Benchmarks are JMH, because a hand-rolled timing loop measures the interpreter and the compiler warming up rather than the thing under test. Sample output is real output. Where the evidence is thin or the sources disagree, nothing is published until it is not.

Marcus Venn · JVM Scope

What gets published, and what does not

Articles fall into five subjects — runtime, concurrency, memory, frameworks and diagnostics — and a topic that fits none of them is out of scope rather than a sixth subject. Within them, the shape is consistent: the finding goes first, the mechanism comes before the advice, and the recommendation is the consequence of the explanation rather than a substitute for it. Length follows the subject, typically eight hundred to twelve hundred words. Nothing is padded to reach a count, and nothing is split into a series to produce more pages; a series exists when several articles genuinely share one idea.

What does not get published is a shorter list, and a firmer one. No framework tutorials, no “top ten” anything, and no takes on which build tool is correct — those are covered adequately elsewhere. No framework advocacy, and no comparison written in order to have a winner. There are no sponsored articles, no affiliate links and no paid placements; nothing appears here in exchange for a link, and guest submissions are not accepted. That last point is not a moral position — it is what keeps an article’s recommendation readable as an actual recommendation.

Code samples are held to the same standard as the prose. They compile against a stated JDK release, they show the flag they need next to them, and they avoid the shortcuts that make a snippet look clean and behave differently from production code. Error handling is sometimes elided for clarity, which the terms of use already state. Technical writing ages, and some of it is wrong on the day it is published: corrections are made in place, a substantively changed article carries an updated date, and if something here is wrong, say so.

How an article is made

The material comes from production. Articles here start from systems that actually ran, misbehaved, and were diagnosed — which is what makes the numbers real, and also what makes a disclosed process necessary rather than optional. Every piece passes through the same three stages, in this order:

1. The author writes the draft. Marcus Venn picks the subject, reproduces the behaviour, and writes the draft around real production examples — the observed symptom, the diagnostic path, the measurement, and the mechanism it points at. All technical substance, every claim and every number, originates at this stage.
2. AI anonymises and copy-edits the draft. A language model strips the identifying detail out of the production examples — employer, client, service and hostname alike — so that a case study cannot be traced back to the system it came from. The same pass fixes spelling, grammar and awkward phrasing, and returns a draft that is ready to publish. It does not introduce claims, numbers or conclusions; its input is the author’s draft and its output is that draft made publishable.
3. The author reviews and signs off. Before anything goes live, Marcus Venn reads the edited draft against the original, corrects whatever the edit distorted, restores any technical nuance the smoothing flattened, and gives the piece its final form. Nothing publishes without that pass, and the byline means it happened.

The division of labour is the point: the findings, the measurements and the judgement are the author’s, the anonymisation and the copy-edit are mechanical, and the last word is the author’s again. An article that could not survive the third stage does not get a fourth one — it is held back or dropped rather than smoothed over.