About JVM Scope
Updated:
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?
Frameworks, standard-library types and runtime flags all present a simple surface. That surface is useful right up until 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. The articles here are written for that moment.
What gets covered
- Runtime behaviour — compilation tiers, deoptimisation, escape analysis, the difference between what the bytecode says and what the CPU executes.
- Concurrency — platform and virtual threads, locks, memory visibility, and the failure modes that only appear under contention.
- Memory and garbage collection — collector trade-offs, allocation profiles, and what pause-time numbers do and do not tell you.
- Frameworks — Spring, Jakarta EE, and the runtime cost of the conveniences they provide.
- Diagnostics — thread dumps, JFR recordings, GC logs, and reading them without pattern-matching on folklore.
How it is written
Claims here are grounded in something checkable: JDK source, a flag’s documented behaviour, or a reproducible experiment with the JDK version and hardware stated. Where a result depends on a specific build, the article says so. Where the honest answer is “it depends, and here is what it depends on”, it says that instead of offering a rule of thumb.
Code samples are meant to be run. They compile against a stated JDK release, and they avoid the shortcuts that make a snippet look clean and behave differently from production code.
The author
Marcus Venn writes about Java, the JVM, and the systems behind production applications. His work explores runtime behavior, concurrency, performance, frameworks, and the trade-offs hidden beneath familiar abstractions. He prefers source code, reproducible experiments, and measurable behavior over rules of thumb. He writes at JVM Scope.
What a typical article looks like
An article here opens with the behaviour in question, states the JDK release and the conditions it was observed under, and then works down to the mechanism responsible. Where a claim can be checked with a flag, the flag is given. Where it can be checked by reading JDK source, the class is named. Where the honest answer is a measurement rather than an argument, the measurement is described precisely enough to repeat.
Length follows the subject. Most pieces run between eight hundred and twelve hundred words, which is long enough to establish a mechanism and short enough to read in one sitting. Nothing is padded to reach a word count, and nothing is split into a series to produce more pages.
Code samples are complete enough to compile and small enough to read. Benchmarks use JMH, because a hand-rolled timing loop measures the interpreter and the compiler warming up rather than the thing under test — a point several articles here make in more detail.
Where to start
If you are new to the site, three articles carry most of the ideas the rest build on. The piece on the JIT and hot loops explains why measurement before warmup is meaningless. The piece on escape analysis explains why allocation counts are not what the source code suggests. The piece on reading thread dumps covers the diagnostic habit that the rest of the diagnostics writing assumes.
Those three form the Reading the runtime series, which is about the same underlying idea: the JVM already reports what it is doing, in considerable detail, to anyone who asks it the right way.
What this site is not
There are no sponsored articles, no affiliate links and no paid placements. Nothing here is published in exchange for a link, and guest submissions are not accepted. This is not a moral position — it is what keeps an article’s recommendation readable as an actual recommendation.
There are also no framework tutorials, no “top ten” lists, and no takes on which build tool is correct. Those are covered adequately elsewhere. The gap this publication tries to fill is the one between a framework’s documentation and the runtime behaviour that documentation does not describe.
Corrections
Technical writing ages, and some of it is wrong on the day it is published. Corrections are made in place, and an article that has been substantively changed carries an updated date. If something here is wrong, say so — a correction is more useful than a comment thread.