Comment by anko | Hacker News Reader

Comment by anko | Hacker News Reader

Parent Full thread

I now manage a team writing languages on the jvm. I have found the jvm ecosystem terrible for observability. Examples;

- junit parallelisation - how are shards handled? how do you balance the tasks across forked processes? What is the bottleneck? Options are 1) pay someone for better tooling or 2) write your own

- long pauses in garbage collection - how do you know which objects are causing the pauses? the options; 1) profiling 2) analysing heap dumps that you periodically capture 3) add metrics or gc logging

- what is the performance bottleneck? options 1) profiling

Sure AI can do this stuff, but it's painful and time consuming

Contrast it to Elixir on the BEAM;

- exunit parallelization - basically free and because you don't have coupling due to OOP. mocks are basically an antipattern

- long pauses due to gc? They just don't happen - everything is isolated and can be cleaned up in parallel.

- performance bottleneck? Open inspector and see what is doing all the reductions, and if any of the inbox queues are backlogged. You don't have to profile, you can just look in production - memory? Open inspector and sort processes by size descending. Again no profiling needed

JFR is what you'd use for everything you need to know. It's depth and breadth are unmatched.

> Contrast it to Elixir on the BEAM;

Java is in the same performance class as C++. BEAM is wonderful in its own way, but it's not even in the same performance class as Go.

BEAM was designed for some interesting resilience in distributed systems. The JVM was designed to address the performance issues that programs in C++ and other low-level languages suffer from when they get large and/or are maintained/evolved for a long time.

> long pauses due to gc? They just don't happen - everything is isolated and can be cleaned up in parallel.

GC pauses in the JVM have been optional for a few years now. ZGC doesn't have GC pauses.

We're talking past each other a bit. I was just trying to give examples of where observability on the jvm isn't that great, because you were were stating it's where AI needs the most help.

The parent was saying these new features don't matter as much post-AI and i think I agree with them. The AI can just write in rust if you need to optimise a hot loop, but if you need observability, you could do worse than the BEAM.

> GC pauses in the JVM have been optional for a few years now. ZGC doesn't have GC pauses.

yeah that's a fair comment, zgc is a lot better for pauses. I'd still say that it pulls along a fair bit of incidental complexity - it encourages you to allocate a fair amount of memory to your heap, which isn't ideal in this world of kubernetes and microservices. If you leave on uncommit (returning memory to he OS periodically) you get extra latency penalties which are just as painful as garbage collection stalls IMHO.

BEAM's observability is very good, but JFR is unmatched. We're not talking about debugging, but about low-overhead deep telemetry (or "always on, in-production profiling"). eBPF helps, but it doesn't come close (e.g. dynamic allocations are much expensive in low-level languages than in Java, but even if you probe malloc, it doesn't tell you the type of the object allocated).

> The AI can just write in rust if you need to optimise a hot loop

Why would it when it could just write it in Java? The JVM was invented not because we couldn't write code in C++ but, among other things, to optimise things (especially around memory management and inlining) that low-level languages have trouble optimising in a large class of applications. If you're after the best performance, then you'll ask AI to use a low-level language when a low-level language offers better performance, and to use Java for applications when Java offers better performance.

Java isn't a performance compromise. It offers different tradeoffs that could make some programs significantly slower than low-level languages in some cases and significantly faster than low-level languages in others. That's the point of the approach taken by the JVM: to offer optimisation opportunities that aren't available in low-level languages. People who think low-level languages always offer better performance are people who have not had much experience with low-level languages. I originally came to Java from C++ because Java has optimisation opportunities that low-level languages don't (they have to compromise on performance in some situations for the sake of low-level control) that matter in certain but very common kinds of programs.

> zgc is a lot better for pauses

It has no real GC pauses. It does have minuscule pauses for synchronisations, but those are an optimisation, and they're no worse than OS jitter. In other words, if ZGC's pauses are a problem for you, then you won't use a non-realtime kernel, as you'll get similar pauses even in a C program on the same OS.

> I'd still say that it pulls along a fair bit of incidental complexity - it encourages you to allocate a fair amount of memory to your heap, which isn't ideal in this world of kubernetes and microservices.

It really doesn't. All of our GCs are optimised for a natural rate of allocation. They do discourage pooling objects to artificially reduce allocation rates, though, but it's easier to not pool than to pool.

> If you leave on uncommit (returning memory to he OS periodically) you get extra latency penalties which are just as painful as garbage collection stalls IMHO.

You get such stalls and worse with C++ or any other low-level language.

ZGC is not pause-free. The only pause-free GC that exists is SGCL for the C++.

ZGC is effectively pause-free. It uses a STW pause for thread synchronisation of the epoch as an optimisation (we tried synchronising without the pause, but OS scheduling just slowed us down; maybe we'll use new OS techniques for synchronisation in the future). ZGC does zero GC work in these pauses. There is also no strong reason to remove the synchronisation pause because it is no longer than OS jitter (i.e. C programs can experience pauses of similar duration on non-realtime kernels).

BTW, SGCL is a non-moving mark-and-sweep collector and non-moving collectors are no more similar to moving collectors than malloc/free is similar to moving collectors. Garbage collection contains different classes of algorithms with different goals that are so different from one another that it's almost pointless to put them in the same category. Java uses moving collectors because it's the class of algorithms designed to reduce the throughput overhead of all non-moving approaches (from manual malloc/free, through automatic RAII and refcounting GC, through tracing mark-and-sweep collectors like SGCL or Go's GC). In important ways, all non-moving approaches are more similar to each other (regardless of the use of a GC) than any of them are to moving approaches. (Java did have a concurrent mark-and-sweep collector at one time, but we removed it some years ago)

Reply on news.ycombinator.com