[aisofteng]

I think that there is probably a large overlap between the population of people who believe this and the population of people that don't really know what bytecode or JIT compilation are.

In fact, I have asked a number of people under the impression that Java is slow to explain why they think it is slow. The answers have two flavors:

1. Its high level abstractions are computationally expensive. Sometimes this idea is supported by saying that garbage collection is very slow, sometimes by saying that the inability to directly manage memory means that it is done inefficiently, perhaps even inescapably so.

2. Compiling a program to an intermediary language that is not assembly but must be instead executed by something else (in this case, the JVM) must be slow.

[wuch]

Controlling memory layout is one area that is very important for performance, where Java does not exactly shines. You essentially have to store your data in arrays of primitive types, to avoid memory overhead of objects (pointer to class, lock, gc bits) and additional indirection during access. While not exactly impossible, Java makes it quite inconvenient and costly to write code that takes control of memory layout.

[pjmlp]

Hence why there are ongoing improvements targeted to Java 10, to change exactly that.

Until then there are the IBM and Azul extensions, off heap memory, or optimizing in native code that 1% after using the profiler, where it really matters.

[therpe1]

It's worth pointing out that:

1) Controlling memory layout is not as big a deal as people think. The JVM is highly optimized (really it's probably the most optimized system ever devised) for allocating and deallocating objects on the heap.

2) It is in fact possible to control memory layout today because Java has access to offheap memory where you can have all the control you want.

This has actually been the case for nearly half a decade but for some reason a lot of people are convinced that "big arrays" can knock over the JVM.

[eru]

Number 2 is especially funny: isn't LLVM doing something similar-ish for C++?

[pjmlp]

Kind of.

In any case, bytecode as executable format, goes back to the early days when CPU were microprogrammed.

It was also a common approach on mainframes, with OS/400 being the best example.