Amen. Control over memory layouts. That would be truly useful for getting reasonable performance. And dropping memory required by the reference hell. Java does

Amen. Control over memory layouts. That would be truly useful for getting reasonable performance. And dropping memory required by the reference hell. Java doesn't support arrays for anything but basic types. Just boolean, byte, char, double, float, int, long. And (object|array) reference. Arrays in Java can have up to 2^31 entries. An array of 2^31 Objects takes 4 * 2^31 (8 GB), with compressed references. Plus of course 8 * 2^31 (8+16 GB) for java.lang.Objects that don't do anything. Smallest usable objects with at least one member would take 16 * 2^31 (8+32 GB) RAM. But this would prevent you from using compressed references (max 32GB heap), which would increase consumed memory to 16+32 GB. Like for example for 2 billion Integers. I realize you wouldn't store integer values this way, the point is integers are about the smallest useful objects imaginable. Java should have true object arrays (like C structs). And how do you align objects to say a cache line? You don't! It's hard to even avoid false sharing in Java. Practically impossible, because you can even get cross-object false sharing due to object memory alignment! Always JITs can be also a bad thing, why bother with code that is very rarely executed? If time it takes to compile + execute compiled version exceeds time it takes to interpret, why bother?