The Go authors had a pretty good article on what&#x27;s wrong with Java&#x27;s performance : pointers everywhere. Every last little thing that isn&#x27;t a primitive type is a pointer. Everywhere, in every bit of code.<p>That means a &quot;new Object()&quot; takes up 16 bytes (8 bytes for the object, 8 for the pointer to it). That means you fill a cache line by allocating 4 objects, or 2 objects containing a single reference, or ...<p>So in java you should never program a line drawing loop by using 2 vectors, because 2 vectors, each with 2 32-bit ints take up 8<i>2 (2 pointers to the objects you&#x27;re using) + 8</i>2 (overhead for the objects) + 4*2 (the actual data) 40 bytes of data. No way you can fit that in registers and still use registers to actually calculate things. So instead you should use 4 ints and just forget about the objects, and even that will only work if you never call any functions.<p>Same loop in C&#x2F;C++&#x2F;Pascal&#x2F;Go&#x2F;... using structs takes 8 bytes (they don&#x27;t keep structs on the heap), which, if necessary, fits in 1 register (granted, in practice we&#x27;re talking 2 registers, but still).<p>People might reply to this with benchmarks, but if you actually analyse the java code where java beats or is comparable with C&#x2F;C++ you&#x27;re going to see zero object allocations. You&#x27;re not even going to see them using bool in the extreme cases, rather they&#x27;ll bitshift into ints to effectively generate packed bools (certainly in SAT benchmarks). This is not realistic java code, which would have been way slower.<p>Java&#x27;s memory model is the main culprit at this point in time. Java can do incredible tricks with programs, and actually exposes them, enabling lots of language creativity on the JVM. But there&#x27;s a pretty sizeable cost in speed and memory usage.