[astrange]

No amount of $ spent on JITs and garbage collection can solve the problem that Java was designed with no respect for memory use. It just doesn’t have the features (such as but not limited to value types) that let you save memory.

They’re adding value types of course, but I haven’t looked at how exactly they’ll work.

[erik_seaberg]

Go is better at keeping values on the stack. Java has better throughput when collecting objects that escaped to the heap.

Java also tries to optimize out method dispatch, so we can use it freely where Go might tend to avoid it.

[astrange]

There's more than just the stack/heap - in a compiled language your constant data is file backed and doesn't need to contribute to memory footprint at all. Java doesn't have that because jar files are missing it (being zipped, syntax that looks like it creates them emit heap allocation bytecode, etc.) and it doesn't have multidimensional arrays or things that might help you use it even if you wrote it in C.

There's some other tricks like tagged pointers, purgeable data it doesn't reliably have either.

[erik_seaberg]

Java NIO can mmap a file of bytes or ints or whatever without using the heap’s private pages, and there are some JVMs that persist and reuse jitted machine code.

I’ve read that games and simulators schedule realtime asset loading pretty carefully; what other problems are solved using large constant data?

[zozbot234]

ZIP does support uncompressed data, so this could easily be added in a backward-compatible way if deemed worthwhile.

[astrange]

Eh you can still have compression, what’s important is the OS pager knows how to read the page from disk as opposed to eagerly loading and swapping it.

[pjmlp]

Until Valhalla arrives, Unsafe package and JNI are options as well.

Or is it ok to use cgo to work around Go's shortcomings, but not JNI for Java's?

[astrange]

Sure it's fine, but isn't that not writing in Java?

I don't remember how good the Java interfaces look though, eg if you worked around no constant data by defining your arrays in C and passing them back, would they be bounds checked arrays?

[pjmlp]

Just like CGO is not Go, yet not a reason to throw everything away.

If one is dumb enough to use C style arrays instead of C++ bounded checked ones, yes that is a problem, again just like C arrays defined in CGO.

[astrange]

> If one is dumb enough to use C style arrays instead of C++ bounded checked ones, yes that is a problem, again just like C arrays defined in CGO.

I'm talking about defining a 'const int[]' in C and having it appear as an 'int[]' in Java. I think that's even less likely to happen if you define a const std::vector.

Actually I've never even seen someone define constant data in C++ using a vector, but this fits my experience of C++ developers telling me I'm stupid when I do the only thing I've ever seen anyone actually write.

[pjmlp]

What can I say, you hang around the wrong people.