Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Don’t call it a comeback: Java is still champ

github.com

Post reply on HN
Print view View original

531–540 of 557 posts

Re: Don’t call it a comeback: Java is still champ

#531

Post by kaba0 »

pkolaczk wrote: post #514
kaba0 wrote: post #499

Earlier quoted context omitted.

Your point on low-latency GCs is indeed fair (read barriers vs write barriers), and I should have probably specified ref counting where the overhead is much more apparent (and is a fairer comparison). But regarding malloc-only, fragmentation also comes into picture which does have a non-negligable effect. And while Java does like to “heap”-allocate, it happens foremost on thread-local buffers and are used pretty much…

> And while Java does like to “heap”-allocate, it happens foremost on thread-local buffers and are used pretty much as an arena allocator. Even without escape analysis, these are very cheap all around. If that was true, it would be fairly easy for Java to come close to C++, C, Rust, Pascal in the "binary trees" microbenchmark in The Computer Language Benchmarks Game. This microbenchmark is the one that stresses dynam…

The binary tree benchmark is made to stress test the GC algorithm, and Java beats out every single managed language by a huge degree. Low-level languages don’t do the same thing for this test, so I don’t really see the point of comparing C vs Java on this test - unless using raw memory buffers would be allowed for java as well.

Re: Don’t call it a comeback: Java is still champ

#532

Post by pkolaczk »

kaba0 wrote: post #531
pkolaczk wrote: post #514

Earlier quoted context omitted.

> And while Java does like to “heap”-allocate, it happens foremost on thread-local buffers and are used pretty much as an arena allocator. Even without escape analysis, these are very cheap all around. If that was true, it would be fairly easy for Java to come close to C++, C, Rust, Pascal in the "binary trees" microbenchmark in The Computer Language Benchmarks Game. This microbenchmark is the one that stresses dynam…

The binary tree benchmark is made to stress test the GC algorithm, and Java beats out every single managed language by a huge degree. Low-level languages don’t do the same thing for this test, so I don’t really see the point of comparing C vs Java on this test - unless using raw memory buffers would be allowed for java as well.

In a comment above you've said Java memory allocation had performance of arena allocators. This benchmark shows such statement is very far from thruth. It is not even close.

The best you can shoot for with Java ZGC is the overhead level of naive C malloc/free (not arena) and only if you give it 5x more heap. You can do better only if you are ok with switching to a GC that does STW, in addition to overblown heap. But even with parallel, STW GC Java is still far from from arena allocators. Which is what I have said in the first comment about picking one feature: throughput, low pauses or memory eficiency.

Re: Don’t call it a comeback: Java is still champ

#533

Post by lispm »

bitwize wrote: post #236
ska wrote: post #89

Earlier quoted context omitted.

I read this was semi-standard memory management in the early lisp machine days, because that gc was so slow.

Early Lisp (even pre-lispm) had no GC at all -- it just allocated until it ran out. Memory reclamation was done by saving the heap to tape and then reading it back -- only live objects were saved. So it was kind of GC with extra steps; the first GC algorithms removed the steps.

Nah, Lisp had GC in 1960 already. McCarthy invented the mark & sweep GC.

Lisp I Programmers Manual, 1960

https://www.softwarepreservation.org/projects/LISP/book/LISP...

Chapter 6.3, Page 95, The Free-Storage List and the Garbage Collector

Re: Don’t call it a comeback: Java is still champ

#534

Post by mcculley »

LaGrange wrote: post #315
mcculley wrote: post #277

Earlier quoted context omitted.

This has not been my experience at all. The JVM is not corrupted by a NPE or out of bounds access unless you are using native code. For example, I worked on a large X-Windows/Motif application with many developers. If some library dereferences a null pointer, it is game over. Kill the app. In a Java Swing app we built for a similar use case, we just trap the exception in the AWT event dispatcher, log it, and keep goi…

> This has not been my experience at all. This has been my experience with software written in Java by developers who think it was not their experience. > In a Java Swing app we built for a similar use case ...oh no. I actually tend to associate Swing UI with weird, undefined behaviors, and whenever I'd look under the hood, it would nearly _always_ be due to them trying to swallow runtime exceptions. Pure hubris, as…

I have the logs from my deployed apps. I know exactly how many times my users are getting those exceptions. We use those logs to fix the bugs and improve our apps.

You seem to have a lot of opinions about my apps from your own unfortunate experiences. Hubris is a word that brings to mind.

Re: Don’t call it a comeback: Java is still champ

#535

Post by mcculley »

pkolaczk wrote: post #517
kaba0 wrote: post #477

Earlier quoted context omitted.

But even race conditions are well-defined in Java: you can’t get so called out-of-thin-air values. Some updates may not be visible from another thread, and of course dead/live locks are on the table (but they are everywhere, even the actor model doesn’t solve those).

> you can’t get so called out-of-thin-air values You can't get out-of-thin-air primitive values (no word tearing). But you can still observe states that cannot be explained by any possible sequential interleaving of your program. E.g. your program can do: a = 0; b = 0; a = 1; b = 1; and another thread that does: print(b) print(a) may observe 4 different combinations of values, surprisingly including also this one: {…

The possibility of these very rare events does not change my mind about best practice for many kinds of deployed applications. I have production apps running right now using this pattern. The users would not be served better by stopping the whole app. We do capture the logs and fix the bugs encountered.

Re: Don’t call it a comeback: Java is still champ

#536

Post by kaba0 »

pkolaczk wrote: post #532
kaba0 wrote: post #531

Earlier quoted context omitted.

The binary tree benchmark is made to stress test the GC algorithm, and Java beats out every single managed language by a huge degree. Low-level languages don’t do the same thing for this test, so I don’t really see the point of comparing C vs Java on this test - unless using raw memory buffers would be allowed for java as well.

In a comment above you've said Java memory allocation had performance of arena allocators. This benchmark shows such statement is very far from thruth. It is not even close. The best you can shoot for with Java ZGC is the overhead level of naive C malloc/free (not arena) and only if you give it 5x more heap. You can do better only if you are ok with switching to a GC that does STW, in addition to overblown heap. But…

I didn’t disagree with your last sentence, but nor is the benchmark evidence against “Java memory allocation having the performance of arena allocators”. The benchmark hardcodes additional information about the problem not available/encodeable in Java according to the rules, so Java has to decide at runtime the lifecycle of each object. That of course have an overhead, but it is not allocation rate, or deallocation rate, as both of those are just pointer bump and reuse region, with the surviving objects copied to another region.

Re: Don’t call it a comeback: Java is still champ

#537

Post by TheRealDunkirk »

pdimitar wrote: post #314
TheRealDunkirk wrote: post #219

Earlier quoted context omitted.

And for the fraction of the software projects out there that that actually need this feature as a hard requirement, I'm sure it's wonderful.

Yeah, all web apps everywhere are definitely a fraction, I'm sure. :P Green threads are an amazing fit for web apps. I made a career out of using those for web apps and API apps.

I've been writing (primarily) web applications for the past 25 years or so, with PHP, .NET, and Ruby. "Scaling many-to-many with stable non-blocking IO and concurrent parallelism that shares memory atomically AND doesn't crash" has never once been an issue that has come up in all of that time.

Re: Don’t call it a comeback: Java is still champ

#538

Post by pdimitar »

TheRealDunkirk wrote: post #537
pdimitar wrote: post #314

Earlier quoted context omitted.

Yeah, all web apps everywhere are definitely a fraction, I'm sure. :P Green threads are an amazing fit for web apps. I made a career out of using those for web apps and API apps.

I've been writing (primarily) web applications for the past 25 years or so, with PHP, .NET, and Ruby. "Scaling many-to-many with stable non-blocking IO and concurrent parallelism that shares memory atomically AND doesn't crash" has never once been an issue that has come up in all of that time.

One anecdote does not cancel another. My response would be: consider yourself lucky. It was an issue in my career, many times.

Re: Don’t call it a comeback: Java is still champ

#539

Post by bigtunacan »

dls2016 wrote: post #176
NoSorryCannot wrote: post #10

Earlier quoted context omitted.

Whoever invented the car analogy should pay for what they did.

I remember an intermediate OO class in Java 20 years ago... the existence of the El Camino was proof of the terribleness of both multiple inheritance and car analogies.

I would love to see the El Camino resurrected, especially as an AWD EV. Sign me up!

Re: Don’t call it a comeback: Java is still champ

#540

Post by msgilligan »

kaba0 wrote: post #169
Cwizard wrote: post #126

Earlier quoted context omitted.

using the parent comments naming scheme it is actually 1.19, I don’t know why they stopped developing major releases however.

1.6 and 1.8 and the like were major releases. While LTS doesn’t have a well-defined meaning for OpenJDK, in general 11+6*n are the versions that are considered LTS (due to other vendors providing paid support for those). Let’s not read more into arbitrary version numbers.

It is now 11 and 17+4n
Post reply on HN