In fact, in certain cases the JVM can detect type information and remove the allocation entirely by hoisting integer fields and the like into registers.
The programmer explicitly specifies when to use pointers. Whenever pointers are not used, the object is stored in-place (for example, on the stack, in the array or slice, or in the struct).
Relatedly, in Go if you allocate an array of n values of type T, the size of that array in memory is n * sizeof(T), and the items are laid out sequentially in memory. There are no other bookkeeping data structures and no indirection.
Here's a story about one project's struggle with data structures and Java: http://marc.info/?l=git&m=124111702609723
Relevant quote:
JGit struggles with not having an efficient way to represent a SHA-1.
C can just say "unsigned char[20]" and have it inline into the
container's memory allocation. A byte[20] in Java will cost an
*additional* 16 bytes of memory, and be slower to access because
the bytes themselves are in a different area of memory from the
container object. We try to work around it by converting from a
byte[20] to 5 ints, but that costs us machine instructions.
It is definitely true that the JVM had been thoroughly road tested compared to Go, but your conclusion is unsound. Go was designed to specifically avoid this pitfall.
OTOH, the memory model of the JVM is intractably linked with its design. Software that runs on the JVM must generate garbage, and so the JVM must include a highly sophisticated GC.
Remember how appallingly bad the JVM was when it was just a few years old? It didn't come close to where we are with Go today. We have only scratched the surface with GC (and other optimizations) for Go.
That's the very reason why some trading companies who still insist on using Java do use methods where as few objects as possible are ever created and went on to invent things like the LMAX disruptor "pattern" (more like an anti-pattern, where the goal is to be as close to the metal as possible, by allocating gigantic primitive arrays... Quite the contrary of your beloved GC dogma, where you think that creating objects as no impact and that slow GCs are necessarily the programmer's fault).
I realize from your various post that you did really drink the Java cool-aid and that no matter what's going to be said you'll always come touting Java as the best language out there.
I know Java well enough to criticize it.
I also have the impression that Go is used inside Google on some impressive tasks so I wouldn't be to quick to dismiss it.
And, BTW, if you think Go has some magic GC secrets that will make all (or even some) of the JVM GC problems go away -- I believe you're mistaken.
With the JVM-based languages I'm familiar with, it is difficult to control the memory allocation characteristics of you program, and typically the further the language deviates from the JVM's model (eg, Clojure and Scala) the more garbage must be generated (usually in doing= things like runtime type reflection).
All these allocations put pressure on the garbage collector and, fortunately, the JVM provides a few sophisticated garbage collectors. But even so, I am aware of some high profile companies whose JVM-based servers spend upwards of 80% of their CPU time in the garbage collector. It's just crazy.
On the other hand, the Go language and - critically - its libraries were designed to give the programmer control over the allocation patterns of the program. This creates less work for the GC, and leads to leaner services with predictable performance characteristics.
Go has other advantages over the JVM as a platform, but this is the critical one IMO.