Java 25's new CPU-Time Profiler

https://mostlynerdless.de/blog/2025/06/11/java-25s-new-cpu-time-profiler-1/

by SerCe • 10 months ago

197 92 10 months ago

mostlynerdless.de

exabrial2• 10 months ago

The JVMin in the last 6-8 years has been a powerhouse of innovation and cool features. Incredibly impressive!

panny• 10 months ago

And a thank you to Oracle for being a good steward of the language.

stickfigure2• 10 months ago

I really don't want to upvote this sentiment but I must anyway.

The fact is, despite Oracle being a menace to the tech industry, Java under their watch is thriving. Which is weird, because I don't know anyone who gives them money for Java. I'm genuinely curious who these companies are and what their incentives are!

parttimenerd4• 10 months ago

And a thank you to all the other amazing companies. The work on the JEP is chiefly sponsored by SAP (with help from Datadog and Amazon).

ksec• 10 months ago

Thank You for giving credit where credit is due, especially on Oracle.

The pendulum is shifting on HN. We can finally give credit to Oracle and Facebook.

tombert• 10 months ago

I never thought I would be excited for a new release of Java, but ever since Java 21, I have grown to actually enjoy writing the language. Whomever is running it has really done a good job making the language actually fun to write in the last few years.

w10-12• 10 months ago

Mark Reinhold runs it, having been there since 1.x days as the core tech lead. He also pushed the move to open source and fast release cycles. But mainly he seems to have recruited and developed good people. I can’t think of a more enduring lead facing more challenges, technical and organizational.

carimura• 10 months ago

Yes Mark is the Chief Architect with vast responsibility, in addition is Chief Language Architect Brian Goetz [1] and the OpenJDK Amber Project members [2][3].

[1] https://inside.java/u/BrianGoetz/

[2] https://openjdk.org/census#amber

[3] https://openjdk.org/projects/amber/

zerr• 10 months ago

If you care about performance at that level, you should not be using Java or any other language with a GC.

pjmlp6• 10 months ago

Thankfully not everyone agrees.

https://www.ptc.com/en/products/developer-tools/perc

We have already have had enough from anti-GC cargo cult from "manual memory management is great" folks.

Having a GC (which RC is also an algorithm subset), doesn't preclude having other features.

OtomotO2• 10 months ago

There is also non manual, non GCed manual management.

I agree that a GC can be a viable implementation of memory management though.

creata2• 10 months ago

Are there any public benchmarks for Perc? Or any hints as to what's going on inside?

mark_l_watson• 10 months ago

There are ways to mitigate this, the fly weight pattern, etc.

pron4• 10 months ago

Modern tracing-moving GCs offer very efficient memory management algorithms that are often hard to beat on performance. Their price isn't so much performance anymore as memory footprint, while manual memory management (and refcounting GCs) optimise not for performance but for footprint (often at the cost of performance). Even this tradeoff is often misunderstood, as covered by this brilliant keynote from the most recent International Symposium on Memory Management: https://youtu.be/mLNFVNXbw7I

arnold_palmur• 10 months ago

In my opinion this is a very outdated opinion.

okokwhatever• 10 months ago

The more I search for a new language to learn the more I want to go back to Java. I feel so nostalgic :)

theanonymousone2• 10 months ago

I have repeatedly said this in multiple occasions: You start to really appreciate Java after you work with other languages.

winrid• 10 months ago

Especially after you inherit a few huge JS or Python projects...

parttimenerd4• 10 months ago

(author here) This is part of a series of blog post. The next blog posts are: https://mostlynerdless.de/blog/2025/07/30/java-25s-new-cpu-t... (on the implementation) https://mostlynerdless.de/blog/2025/08/25/java-25s-new-cpu-t... (on sizing the queue) and a fourth on improving the performance: https://mostlynerdless.de/blog/2025/09/01/java-25s-new-cpu-t...

eduction• 10 months ago

Maybe add those links in the posts themselves. The first one mentions what the second one will be about, you could just turn that into a link. Or have a bullet list of all the links you add to each post in the series.

parttimenerd4• 10 months ago

Thanks for the recommendation.

w10-12• 10 months ago

This is built on a Linux sampling API that offers more accuracy, but it is still sampling.

For CPU tracing, with no sampling errors, use Apple’s M4 with the latest Xcode’s Instruments.

parttimenerd4• 10 months ago

(author here)

Xcode doesn't know about Java's internals, so it doesn't know about Java frames, although it can help with native traces.

rr8082• 10 months ago

I just hope with new lightweight threads I never have to write async reactive code again. It was a such an unproductive mistake, most applications do not need that level of complexity - now we can confidently say no applications need that level of added complexity.

mrkeen• 10 months ago

It was a better model for reasoning about concurrency, i.e. evaluate two expressions, rather than where virtual threads is headed, i.e. "you don't have to learn anything" - just spawn two threads, keep writing sequences of statements and pretend nothing's changed since the 90s.

https://www2.eecs.berkeley.edu/Pubs/TechRpts/2006/EECS-2006-...

piokoch• 10 months ago

Well, I hoped too. The problem is that "lightweight" are not that lightweight, as they need garbage collection. So, in theory, one can create 100K threads on one machine, but in practice that's going to keep burning processor for GC cycles.

Another thing is what those lightweight threads are doing? If they play with CPU that's ok, you pay GC penalty and that's all. But if they access limited resources (database, another HTTP service), etc. in real application you face the standard issue: you cannot hit the targeted system with any data you want, this external system will backfire, sooner or later.

The good thing in reactive programming is that it does not try to pretend that above problem does not exist. It forces to handle errors, to handle backpressure, as those problems will not magically disappear when we switch to green threads, lightweight threads, etc. There is no free lunch here, network has its restrictions, databases has to write do disk eventually, and so on.

kdps2• 10 months ago

So, in theory, one can create 100K threads on one machine, but in practice that's going to keep burning processor for GC cycles.

The focus on "100k threads" and GC overhead is a red herring. The real win isn't spawning a massive number of threads, but automatically yielding on network I/O, like e.g. goroutines do. In an I/O bound web application, you'd have a single virtual thread handling the whole request, just like a goroutine does. The GC overhead caused by the virtual thread is minuscule compared to the heap allocations caused by everything else going on in the request. If you really have a scenario for 100k virtual threads, they would not be short lived.

But if they access limited resources (database, another HTTP service), etc. in real application you face the standard issue: you cannot hit the targeted system with any data you want

Then why would you do it? That sounds like an architectural problem, not a virtual thread problem. In an actor system, for example, you wouldn't hit the database directly from 100k different actors.

The good thing in reactive programming is that it does not try to pretend that above problem does not exist.

This compares a high-level programming paradigm, complete with its own libraries and frameworks, to a single, low-level concurrency construct. The former is a layer of abstraction that hides complexity, while the latter is a fundamental building block that, by design, does not and cannot hide anything.

It forces to handle errors, to handle backpressure, as those problems will not magically disappear when we switch to green threads, lightweight threads, etc.

Synchronous code handles errors in the most time-tested and understandable way there is. It is easy to reason about and easy to debug. Reactive programming requires explicit backpressure handling because its asynchronous nature creates the problem in the first place. The simplest form of "backpressure" in synchronous code with a limited amount of threads is the act of blocking. For anything more than that, there are the classic tools (blocking queues, semaphores...) or higher-level libraries built on top of them.

vips7L7• 10 months ago

Even for the applications that need reactive I do wonder if anyone has actually done the financial analysis between the extra developers and development time needed for reactive vs just throwing more servers at the problem.

treyd2• 10 months ago

C10k is basically just impractical without reactive / async / coroutines / that style. But with it it's extremely achievable on even midrange consumer hardware depending on the specific workload.

back2dafucha• 10 months ago

The biggest problem with Java these days is java developers are not really good at all. I would say n the last 10 years 99 percent of "Java" devs cant competently read a stack trace.

Im not sure why anyone would improve this language when the developers are so frankly pathetic. Let them use 1.8. The ecosystem has improved. Devs have gotten worse.

Java has become a land of opportunists just trying to pass of their non-Java maybe non-programmer skills

jmpavlec• 10 months ago

Really curious what makes you say this. Do you see the same thing in other languages? I've worked with many great Java devs over the years and think I'm halfway decent myself after working with it for 16+ years. Are there some bad ones in between? Sure, but that's true of any language (especially javascript).

janwas• 10 months ago

CPU-time would over-emphasize regions where many threads are running, right? I find wall-time useful for finding serial regions that aren't yet parallelized.

More detail here: https://github.com/dvyukov/perf-load. We recently implemented the same idea without requiring context-switch events: https://github.com/google/highway/blob/master/hwy/profiler.h...

Java 25's new CPU-Time Profiler

Related Stories