IT Runs on Java 8

Re:IT Runs on Java 8 by endymi0n on Friday May 10, 2019 @05:39PM (#19882494)

Funnily enough, Go just chose to solve the problem the other way around: While JVM tackled GC with the code equivalent of lightsaber-equipped drones, Go‘s GC is almost embarrassingly simple in comparison (although it‘s pretty decent by now).

The major difference is that the whole Go language and stdlib is simply written around patterns that avoid allocations almost magically. The simplicity of the Reader and Writer concepts is so elegant, yet powerful and doesn‘t allocate anything but a tiny reused buffer on the stack. There‘s lots and lots of other examples, but if you have to collect ten times less garbage, you‘ll be better off, even if your GC is 2x slower.

[ Parent | on HN ]

Re:IT Runs on Java 8 by pcwalton on Friday May 10, 2019 @06:06PM (#19882710)

The byte buffers that Go's Reader reads from and that Go's Writer writes into cannot in general be allocated on the stack because they are considered to escape. Because Reader and Writer are interfaces, calls are dispatched virtually, so escape analysis cannot always see through them. This is now fixed for simple cases in Go, but only very recently: https://github.com/golang/go/issues/19361

Ironically, Java HotSpot handles the use case of Reader and Writer better than Go does, since when it's not able to allocate on the stack it has fast allocation due to the use of a generational GC with bump allocation in the nursery. By virtue of the fact that it's a JIT, HotSpot can also do neat things like see that there's only one implementation of an interface and thereby devirtualize calls to that interface (allowing for escape analysis to kick in better), something Go cannot do in general as it's an AOT compiler.

[ Parent | on HN ]

Re:IT Runs on Java 8 by pron on Friday May 10, 2019 @06:52PM (#19883019)

> like see that there's only one implementation of an interface and thereby devirtualize calls to that interface

Oh, the JIT devirtualizes and inlines even if there are many implementations, but only one or two at a particular callsite. This has been generalized in Graal/Truffle so you almost automatically get stuff like this (https://twitter.com/ChrisGSeaton/status/619885182104043520, https://gist.github.com/chrisseaton/4464807d93b972813e49) by doing little more than writing an interpreter.

[ Parent | on HN ]

Re:IT Runs on Java 8 by pron on Friday May 10, 2019 @06:55PM (#19883039)

I agree it's impressive that Go manages to be not all that much slower than Java while having a much simpler runtime, but much of the simplicity is gained from lacking features that are very important in many cases of "serious software" like deep low-overhead continuous profiling and ubiquitous dynamic linking.

[ Parent | on HN ]

Re:IT Runs on Java 8 by wikibob on Friday May 10, 2019 @08:24PM (#19883559)

I’ve seen you mention the superior operability of Java and the JVM in high load production environments and I think this is a really important, often overlooked, and commonly misunderstood point.

Would you be up for writing a short post or blog post going into some anecdotal comparisons and sharing some resources?

[ Parent | on HN ]

Re:IT Runs on Java 8 by tomohawk on Friday May 10, 2019 @05:55PM (#19882609)

Exactly. Go is benefiting from years of hard lessons learned in other stacks such as Java. Having super experienced GC builders involved early on resulted in a language and libraries that work much more synergisticaly with the GC.

It's better to dodge a problem, than to have a baked in problem that requires lots of really smart people to make work arounds.

[ Parent | on HN ]