[pron]

You're mixing two things here: memory management and memory layout. This "pointer-heavy programming" is, indeed, a bad fit for modern hardware in terms of processing speed due to cache misses, which is why even Java is now getting user-defined primitive types (aka inline types, aka value types), but in terms of memory management, in recent versions OpenJDK is pretty spectacular, not only in throughput but also latency (ZGC in JDK 16 has sub millisecond maximum pause time for any size of heap and up to a very respectable allocation rate: https://malloc.se/blog/zgc-jdk16 and both throughput and max allocation rate are expected to grow drastically in the coming year with ZGC becoming generational). As far as performance is concerned, GC can now be considered a solved problem (albeit one that requires a complex implementation); the only real price you pay is in footprint overhead.

[StefanKarpinski]

I'm not — memory layout and memory management are (fairly obviously, I would think) intimately related. In particular, pointer-heavy memory layouts put way more stress on the garbage collector. Java's choice of making objects mutable, subtypeable and have reference semantics, basically forces them to be individually heap-allocated and accessed via pointers. On the other hand, if you design your language so that you can avoid heap allocating lots of individual objects, then you can get away with a much simpler garbage collector. Java only needs spectacular GC technology because the language is designed in such a way that it generates a spectacular amount of garbage.

[pron]

I would say no. To have stellar performance, you'll need compaction, you'll need parallelism (of GC threads), and you'll need concurrency between the GC threads and mutator threads; and for good throughput/footprint tradeoff you'll need generational collection. True, you might not need to contend with allocation rates that are that high, but getting, say, concurrent compaction (as in ZGC) and/or partial collections (as in G1), requires a sophisticated GC. E.g. Go isn't as pointer-heavy as (pre-Valhalla) Java, and its GC is simple and offers very good latency, but it doesn't compact and it throttles, leading to lower throughput (I mean total program sluggishness) than you'd see in Java, even with a much higher allocation rate. The thing is that even with a low allocation rate, you'd get some challenging heaps, only later, say, every 10 seconds instead of every 5.

It's true that a simpler GC might get you acceptable performance for your requirements if your allocation rate is relatively low, but you still won't get OpenJDK performance. So I'd say that if you design your language to require fewer objects, then you can get by with a simple GC if your performance requirements aren't too demanding.

All that dereferencing puts a higher load on data structure traversal (which is why Java is getting "flattenable" types) than on the GC. The main reason for Java's particular GC challenges isn't its pointer-heavy (pre-Valhalla) design but the mere fact that it is the GCed platform that sees the heaviest workloads and most challenging requirements by far. Java's GC needs to work hard mostly for the simple reason that Java is asked to do a lot (and the better some automated mechanism works, the more people push it).

[bbatha]

Go has only concurrency of the features you talk about but is often competitive with Java in benchmarks. In my experience I’ll take administration of go processes any day of the week over Java — I’ve lost count of the number of hours lost to debugging gc stalls, runaway heaps and other garbage collector related issues never once had those problems in go.

Go even reverted a generational collector because it had no performance benefits since most generational objects would be stack allocated anyway — Julia’s JIT and way more advanced llvm backend should do even better than go in keeping objects stack local and inline.

[pron]

It's competitive in pretty forgiving benchmarks. And LLVM is way more advanced than Go's compiler, but not OpenJDK's. I'm not saying you have to prefer Java to Go, but its throughput is better. As to the stack-allocation claim, young generations might be hundreds of MBs; that might correspond to the stacks of 100K goroutines on some server workloads, but not of a few threads.

So I'm not saying you must prefer Java to Go (even though GC tuning is a thing of the past as of JDK 15 or 16), or that Go's performance isn't adequate for many reasonable workloads, only that 1. a flatter object landscape might still not match Java's memory management performance without sophisticated GCs, and 2. I wouldn't extrapolate from Go to Julia, as they are languages targeting very different workloads. E.g. Julia might well prefer higher throughput over lower latency, and Go's GC's throughput is not great.

[snovv_crash]

Having a Lamborghini racing a Toyota Corolla is of course going to show the Lambo winning. But if I need to maintain a fleet of them to move 1000 passengers around a city with certain availability guarantees, I'm going with the Toyotas every time.

[pjmlp]

Likewise if I do races for living I am picking the Lamborghini.