Java Turns 25 – Whats Next? [pdf] • Hacker News Board

Re: Java Turns 25 – Whats Next? [pdf]

#201

Post by throwaway189262 » Mon, Sep 21, 2020, 5:16 AM UTC

titzer wrote: post #196

throwaway189262 wrote: post #193

Earlier quoted context omitted.

I don't agree with your pause time estimates. Most collectors are fast with small amounts of garbage in a small application. It's high allocation rates where GC time becomes a problem, and I don't see anything about Go or V8 designs to prevent very bad worst-case pause times. Uh, most of the rant about Go GC below is out of date, they made some huge improvements from 2016-now. I'm leaving it up because someone replie…

> I don't know much about V8 collector besides that it is generational and compacting, so more modern than Go. But it's still a "stop the world" design. In that regard it's still closest to Javas old CMS collector. > ... In V8 or Go, this would be many seconds pause time as the mark phase is "stop the world" in both. Like I said before, your information is outdated. V8 has both incremental and concurrent marking. I e…

V8 still uses STW for mark sweep. The benchmark image on this https://v8.dev/blog/concurrent-marking shows 50+ms pause time, quite bad compared to ~5ms or less in new Java collectors. This might be due to STW move phase though? They don't really explain, but the long pause times show that there's definitely still long STW pauses in V8.

For Go, I'm going to be a bad HN user and not read the whole article. Sorry, it's just too long for this time of night. It does appear that my understanding of Go GC is out of date. There's been many improvements in the last couple years. Some strange behavior due to not enough knobs to configure GC, but it appears to have a near constant GC pause? https://blog.twitch.tv/en/2019/04/10/go-memory-ballast-how-i...

I'm annoyed that Google doesn't offer much benchmarking results for V8. Huge articles about improvements made with a single benchmark image. And they didn't use standard benchmarks for either so it's unclear what they're even benchmarking. The Go slides you linked include benchmarks from some guys production server he tweeted images of, a bunch of standard benchmarks but they only show % throughout improvement, and no pause times.

Re: Java Turns 25 – Whats Next? [pdf]

#202

Post by pjmlp » Mon, Sep 21, 2020, 5:18 AM UTC

saagarjha wrote: post #149

pjmlp wrote: post #120

Earlier quoted context omitted.

Nope, Java 8 nowadays. https://developer.android.com/studio/write/java8-support All libraries that matter on the Java eco-system are already on Java 11.

Android's Java is like half of Java 8 :/

Yeah, Android Java has turned into Google's own version of J++.

Worse is that Kotlin fanboys don't get it, that without access to modern Java their Java FFI is worthless, as all Java 8+ libraries on Maven Central will slowly become useless on Android no matter what.

Additionally the language cannot expose JVM capabilities, unless they had even another backend.

So it will be stuff like value types, JNI replacement, proper generics, customized JIT and SIMD on the JVM, and plain old Java 8 on ART.

Re: Java Turns 25 – Whats Next? [pdf]

#203

Post by billyjobob » Mon, Sep 21, 2020, 5:21 AM UTC

rzwitserloot wrote: post #29

lchengify wrote: post #17

Earlier quoted context omitted.

Other than Effective Java, I recommend looking at some of the Google libraries, specifically Guava [1] and Guice [2] for dependency injection. Java is fundamentally a slow adopter of new techniques (it just got lambdas in JDK 8), but a lot of the Google libraries fill in the gaps. Note that if you are learning Java for Android development, that's a whole different sub-discipline. In that case I recommend the Android…

> (it just got lambdas in JDK 8) Interesting use of the word 'just'. At the risk of making readers feel old... Java 8 was released _6 and a half years ago_.

Many Java shops are only just upgrading to JDK 8 though.

Re: Java Turns 25 – Whats Next? [pdf]

#204

Post by hilbertseries » Mon, Sep 21, 2020, 5:37 AM UTC

spullara wrote: post #127

coliveira wrote: post #39

Earlier quoted context omitted.

The main problem with Java is its concurrency model, which gives incentive to the creation of threads that fight for resources and introduce bugs. This seemed a wise choice in the 90s, but as concurrency has increased several-fold in the last 25 years, the model cannot scale to real software needs. It is the Java equivalent to pointers in C.

Amusingly, Loom, which will likely appear in the Java 17 time-frame will allow you to use all that blocking code and it automatically transforms it into non-blocking code. Going to make coding high-concurrency applications a lot easier. Check out the few lines of code needed to convert Jetty from blocking to non-blocking: https://github.com/rodrigovedovato/jetty-loom/blob/master/sr...

I'm very skeptical of this conversion into loom. Jetty bounds the number of concurrent requests it serves based on the size of its thread pool (of course Jetty also uses a few of the threads to run its acceptors and selectors). The implementation provided here, replaces Jetty's fixed sized thread pool with an unbounded thread pool. This is going to lead to some terrible failure states when the service slows down.

Re: Java Turns 25 – Whats Next? [pdf]

#205

Post by titzer » Mon, Sep 21, 2020, 5:41 AM UTC

throwaway189262 wrote: post #201

titzer wrote: post #196

Earlier quoted context omitted.

> I don't know much about V8 collector besides that it is generational and compacting, so more modern than Go. But it's still a "stop the world" design. In that regard it's still closest to Javas old CMS collector. > ... In V8 or Go, this would be many seconds pause time as the mark phase is "stop the world" in both. Like I said before, your information is outdated. V8 has both incremental and concurrent marking. I e…

V8 still uses STW for mark sweep. The benchmark image on this https://v8.dev/blog/concurrent-marking shows 50+ms pause time, quite bad compared to ~5ms or less in new Java collectors. This might be due to STW move phase though? They don't really explain, but the long pause times show that there's definitely still long STW pauses in V8. For Go, I'm going to be a bad HN user and not read the whole article. Sorry, it's…

> V8 still uses STW for mark sweep.

Well unfortunately you are still misunderstanding, so let me be more precise so we are talking about the same thing. V8 uses incremental marking (i.e. splitting mark work into smaller chunks and interleaving those chunks with mutator time) as well as concurrent marking (i.e. multiple parallel collector threads marking in the background, concurrent with the mutator). Not mentioned in the article, but sweeping of pages is also incremental (i.e. dead space reclaimed on-demand when free lists run empty) and concurrent when idle (i.e. in the background). So the statement "V8 still uses STW for mark sweep" is just wrong. Like I said before, V8 only stops the world for semispace scavenges (fast, You also misunderstood what is reported here. That 50ms main thread marking time is cumulative, meaning those 50ms are spread over the entire garbage collection cycle, split up into small increments so that the mutator (main thread) is not stopped the entire time. It's explained there in the text and illustrated in the second-to-last diagram.

> quite bad compared to ~5ms or less

Again, it is not 50ms pause, it's 50ms work, split into much, much smaller incremental pauses, typically less than 1 ms each. That number is not presented in your linked article but is pretty typical. The V8 GC needs sub-millisecond pause times because it has a soft realtime requirement in that it may end up on the critical path for frame rendering (60fps = 16.6ms).

> For Go, I'm going to be a bad HN user and not read the whole article.

FTA "...The August 2017 release saw little improvement. We know what is causing the remaining pauses. The SLO whisper number here is around 100-200 microseconds and we will push towards that. If you see anything over a couple hundred microseconds then we really want to talk to you and figure out whether it fits into the stuff we know about or whether it is something new we haven't looked into. In any case there seems to be little call for lower latency. It is important to note these latency levels can happen for a wide variety of non-GC reasons..."

TLDR: if you see pause times of more than a couple hundred microseconds, call the red phone.

Also, please note, I am just trying to provide accurate information about the collectors I do know about, designed by people I work(ed) with. I don't know enough about ZGC or Shenenadoah to confidently assert anything about their performance characteristics, but based on what I read I am actually very excited to see them make it into production. I consider advances in GC to be overall a good thing for everyone, and would encourage you to be more open to learning the advantages and disadvantages of various systems without as much derision and not try to pick sides.

Re: Java Turns 25 – Whats Next? [pdf]

#206

Post by binaryjay » Mon, Sep 21, 2020, 5:42 AM UTC

pjmlp wrote: post #107

bandris wrote: post #94

Earlier quoted context omitted.

Actually BEAM and Erlang pre-dates Java. ;-) As for compatibility: why is Java 8 market share so high in 2020?

Shitty Android.

More like shitty Java. I'm glad Java is being relegated to a second class language that is not recommended for Android development. Kotlin is the now the recommended language for Android development. I give Google 2-3 years before they deprecate Java from Android.

Re: Java Turns 25 – Whats Next? [pdf]

#207

Post by hilbertseries » Mon, Sep 21, 2020, 5:42 AM UTC

titzer wrote: post #196

throwaway189262 wrote: post #193

Earlier quoted context omitted.

I don't agree with your pause time estimates. Most collectors are fast with small amounts of garbage in a small application. It's high allocation rates where GC time becomes a problem, and I don't see anything about Go or V8 designs to prevent very bad worst-case pause times. Uh, most of the rant about Go GC below is out of date, they made some huge improvements from 2016-now. I'm leaving it up because someone replie…

> I don't know much about V8 collector besides that it is generational and compacting, so more modern than Go. But it's still a "stop the world" design. In that regard it's still closest to Javas old CMS collector. > ... In V8 or Go, this would be many seconds pause time as the mark phase is "stop the world" in both. Like I said before, your information is outdated. V8 has both incremental and concurrent marking. I e…

Go also has simplified their heap from Java's in a notable way, you cannot set a limit to Go's heap. You can set a limit to the memory used by the Go process, of course.

Re: Java Turns 25 – Whats Next? [pdf]

#208

Post by nsxwolf » Mon, Sep 21, 2020, 5:44 AM UTC

WalterBright wrote: post #96

hn_throwaway_99 wrote: post #87

Earlier quoted context omitted.

Ironically, while Java was the original "write once, run anywhere" language, it never succeeded in that regard (e.g. browser applets were never popular). Ironically, I believe Javascript has. I was pretty much exclusively a Java programmer for the first decade and a half of my career, before moving to Node and TypeScript. I don't think I could ever go back at the point. Most importantly, this is my first time where t…

> Java was the original "write once, run anywhere" language That crown properly belongs to the UCSD P-System, which was the Java of the 1980's. It was the same idea as Java - compilation to a bytecode which an interpreter ran. It failed because the interpreter performance penalty was too high. Java also started out as an interpreter, which made it too slow. Steve Russell of Symantec invented a JIT for it, and like th…

I also wonder how much the difficulty of sharing files between different systems due to different disk formats played a role in its failure.

You could run p-system on a lot of machines - Apple II, IBM PC, TI-99/4A, PDP11... but how would you (and why would you) distribute your code across machines with such different storage media?

Re: Java Turns 25 – Whats Next? [pdf]

#209

Post by hilbertseries » Mon, Sep 21, 2020, 5:45 AM UTC

throwaway189262 wrote: post #131

philipkglass wrote: post #118

Earlier quoted context omitted.

I'll shamefully admit that I have been running and writing JVM based services for years and I didn't know this. I thought that the fixed memory overhead for a simple JVM service was simply higher than with CPython as a fact of life. There are times when I'd happily trade more frequent GC pauses for a smaller per-process memory footprint. How do you find a reasonably small Xmx that doesn't lead to OutOfMemoryError exc…

> How do you find a reasonably small Xmx that doesn't lead to OutOfMemoryError exceptions? That's tough to figure out. In new versions of Java, I think 14+, if you use ZGC collector it will return unused memory to the OS. Memory options vary depending on collector, but new versions of ZGC support "soft max" heap size and uncommit. Together it might be close to what you're looking for https://malloc.se/blog/zgc-softma…

> I should mention the GC situation was worse until the last few years. Until ZGC and Shenandoah came around, Java still didn't collect frequently but when it did there were long pauses.

This feels like G1GC erasure. I'll also say we've tried out ZGC and while pause times were low, it had a huge CPU overhead and the performance of our application was notably worse and we went back to G1GC. We're still on Java 11, so maybe we'll see some magic when we eventually try the newer versions.

Re: Java Turns 25 – Whats Next? [pdf]

#210

Post by hota_mazi » Mon, Sep 21, 2020, 5:50 AM UTC

pjmlp wrote: post #200

hota_mazi wrote: post #187

Earlier quoted context omitted.

Android moved past the Java restriction ten years ago. First by adding their own features to the JDK, and today simply by making Kotlin the main language to program in on Android. Android is completely unshackled from Java today. Android is compeltely

On the contrary, without access to Maven Central ecosystem of Java libraries, it quickly loses interest as development platform.

What does Maven Central have to do with the development of Java by Oracle?

That is precisely my point.

Android has completely unshackled itself from Java development. Between its reliance on Open JDK and Kotlin, it literally has zero dependencies on Java.