[iofj]

Maybe I'm unclear on some of the details here, but here goes

https://docs.oracle.com/javase/specs/jls/se8/html/jls-12.htm...

"Whenever a new class instance is created, memory space is allocated for it with room for all the instance variables declared in the class type and all the instance variables declared in each superclass of the class type, including all the instance variables that may be hidden (§8.3)."

Doesn't seem to allow for escape analysis eliminating the object. Plus escape analysis wouldn't really save you. These are class instances, you pretty much have to declare them before the scope you use them in, if you're using them in the condition of a while loop (which would be the way to use them).

I seem to have this experience in practice. If you have a value type and loop over it, creating a "dummy" instance of it outside of the loop, then erase and reset it's inner state on every loop iteration is far faster than creating an instance inside the loop. So I don't think escape analysis optimizes this case.

[pjmlp]

Because JIT compilers are able to bend the rules if proven correct.

For example, if you declare something like

    final class Point {
          final int x, y;

          //...
    }

The Azul JIT compiler will transform it into a struct, just like in C, via their "StructuredArray and ObjectLayout" optimizations.

IBM J9 also does similar optimizations via packed objects, as they call it.

JIT compilers also remove locks and synchronized blocks if heuristics prove their are never needed in the dataflow.

In any case, by Java 10, real value types are expected to be part of the language.

[iofj]

Even if you're right. The issue with coding to optimizations is that it's really, really brittle. You change the position of a variable and suddenly your application runs 10x slower.

Why ? Because it just went from O(N) with no allocations to O(N^2) because it has to constantly extend and walk a list (the free memory list, which is lower bounded by the number of iterations of the loop) on every iteration of the loop (malloc is O(N), so calling malloc in a loop automatically increases it's complexity, and compilers change stack allocations into mallocs due to optimizations).

I've seen this happen many times. And then, after 2 weeks of searching you find the cause : someone changed 3 * i into i * 3 in a method which caused autoboxing to suddenly actually occur.

Counting on compiler optimizations to save your ass is incredibly, incredibly brittle.

[pjmlp]

> Even if you're right.

I can provide some presentations from Java Language Summit

> Counting on compiler optimizations to save your ass is incredibly, incredibly brittle.

I agree.

Ada, Delphi, Modula-3, Oberon or Eiffel could have been in Java's place with the right stewardship, but sadly it wasn't it.

I also don't see it getting replaced anytime soon, hence why I welcome the idea of eventually getting value types and proper AOT on the reference JDK while keeping the huge set of libraries that we have available.

In any case, I am both a language geek and a polyglot developer, so I have fun discussing this kind of subjects not being language zealot.