Go's GC is much more naive than modern Java GCs, and the codegen is not terrific.
That said: A few design decisions in the Java language (that are only slowly getting fixed) harm performance:
1. "Everything is virtually dispatched" reduces the ability to make inlining decisions sensibly.
2. Escape analysis gets harder (and less effective), leading to moving fewer variables onto the stack.
3. The poor support for allocating compound data types on the stack.
All of these conspire to create many more heap allocations than comparable Go code, so even if the GC is much better, the amount of work it has to do is much bigger.
Achieving any form of data locality in Java is also hard because it's really hard to nest structs.
The Java design shows that the memory wall wasn't a thing yet when the language was designed...
Things are slowly getting fixed, and there's a lot of interesting off-mainstream stuff that can be done to get more perf in Java-Land (Azuls JVM, Graals AoT etc) - but the strange thing is that Java does pay for some outdated design choices while Go performs pretty well despite a very simplistic implementation...
That is a good point, but soulbadguy was pointing out that if you make a (non-static) method "final" then you can't override it in a subclass, which should have the same effect, without having to change the semantics by making the method "static".
That said, if there are no actual subclasses of a given class, the JVM will know that, and should be able to inline functions as necessary. That is complicated quite a bit by the fact there is no exhaustive list of which classes are available (the JVM only knows which classes it's seen), and that new classes can be added during the runtime (e.g. Tomcat will load a WAR at startup which will add new classes, or Maven might download a plugin and execute code). But if that _doesn't_ happen, i.e. you load a class and the JVM never sees a subclass and it decides to optimise that part of the code then it will inline what it can (and un-inline it if a subclass shows up later.)
That said: A few design decisions in the Java language (that are only slowly getting fixed) harm performance:
1. "Everything is virtually dispatched" reduces the ability to make inlining decisions sensibly. 2. Escape analysis gets harder (and less effective), leading to moving fewer variables onto the stack. 3. The poor support for allocating compound data types on the stack.
All of these conspire to create many more heap allocations than comparable Go code, so even if the GC is much better, the amount of work it has to do is much bigger.
Achieving any form of data locality in Java is also hard because it's really hard to nest structs.
The Java design shows that the memory wall wasn't a thing yet when the language was designed...
Things are slowly getting fixed, and there's a lot of interesting off-mainstream stuff that can be done to get more perf in Java-Land (Azuls JVM, Graals AoT etc) - but the strange thing is that Java does pay for some outdated design choices while Go performs pretty well despite a very simplistic implementation...