OpenJDK 15 To Have Better Out-Of-The-Box Performance

[Sin2x]

Michael Could you add the Eclipse OpenJ9 vm to your java benchmark please ? It targets fast start, and lower memory footprint (for containers for example) :
https://www.eclipse.org/openj9/

I second that request. Eclipse foundation seems to be doing a great job there.

[chrisr]

Meh. Major versions of java also contain other differences - how long until Java Reflection is nerfed into uselessness, for example? So adding performance fixes into a "next" major Java version doesn't impress me in the slightest.

Are any of these performance fixes going to be back-ported into any of the LONG-TERM STABLE releases, such as JDK8 or JDK11? (Hint: the clue is in the name...)

[bug77]

Meh. Major versions of java also contain other differences - how long until Java Reflection is nerfed into uselessness, for example? So adding performance fixes into a "next" major Java version doesn't impress me in the slightest.

Are any of these performance fixes going to be back-ported into any of the LONG-TERM STABLE releases, such as JDK8 or JDK11? (Hint: the clue is in the name...)

The correct name is "Long-Term Support"

And reflection is the kind of the elephant in the room: it's required for some specific functionality, but it throws a monkey wrench into the efforts to compile Java to native code, which, in turn, is kind of required if Java is to have a place into a microservices world.

[chrisr]

And reflection is the kind of the elephant in the room: it's required for some specific functionality, but it throws a monkey wrench into the efforts to compile Java to native code, which, in turn, is kind of required if Java is to have a place into a microservices world.

I don't give a rats rear-end about the micro-services world. Our platform uses reflection - needs reflection - to make certain operations work (e.g. serialization of certain Java types, working around design flaws in third party classes etc) and this recent frantic scramble to Java 9,10,11,12,..... is leaving us high and dry. I sincerely doubt we're the only such case either. We're actually still migrating from Java 8 to Java 11 but are being hampered by a stream of bugs in the crypto code, the fixes for which don't seem to be landing downstream either. If someone is trying to sabotage the OpenJDK project then they're going the right way about it.

[bug77]

I don't give a rats rear-end about the micro-services world. Our platform uses reflection - needs reflection - to make certain operations work (e.g. serialization of certain Java types, working around design flaws in third party classes etc) and this recent frantic scramble to Java 9,10,11,12,..... is leaving us high and dry. I sincerely doubt we're the only such case either. We're actually still migrating from Java 8 to Java 11 but are being hampered by a stream of bugs in the crypto code, the fixes for which don't seem to be landing downstream either. If someone is trying to sabotage the OpenJDK project then they're going the right way about it.

Serialization is done mostly through JSON these days and I certainly hope you're not suggesting the core JDK should be developed in such way as to accommodate poor practices in random libraries.
You only truly need reflection when you're loading stuff dynamically. Applications should never need to do this, this is a feature for underlying frameworks or libraries.

[chrisr]

Serialization is done mostly through JSON these days and I certainly hope you're not suggesting the core JDK should be developed in such way as to accommodate poor practices in random libraries.
You only truly need reflection when you're loading stuff dynamically. Applications should never need to do this, this is a feature for underlying frameworks or libraries.

Serialization is done by whatever does serialization, and JSON is only one such method. (Think about it - how do you think JSON serialization libraries like Jackson's ObjectMapper work in the first place?) The bottom line is that the JDK is throwing compatibility with its existing ecosystem out of the window, and not everyone is willing to follow where it is going.

[bug77]

Serialization is done by whatever does serialization, and JSON is only one such method. (Think about it - how do you think JSON serialization libraries like Jackson's ObjectMapper work in the first place?) The bottom line is that the JDK is throwing compatibility with its existing ecosystem out of the window, and not everyone is willing to follow where it is going.

I'm sure you wanted to explain something to me there, but you got me thoroughly confused instead.
I was merely suggesting if serialization is what's holding you back, you should do what the modern world does and switch to using JSON. That doesn't need serialization. It does serialize/deserialize things, but it's not using Java's built-in serialization mechanism (that's why it doesn't require Serializable, but accepts Object instead).
As for compatibility, it's been discussed before. Besides some ancient things, nothing has been removed that. Some things have been marked deprecated and may not be part of the core JDK anymore, but everything is still available for the time being.

[chrisr]

I was merely suggesting if serialization is what's holding you back, you should do what the modern world does and switch to using JSON. That doesn't need serialization. It does serialize/deserialize things, but it's not using Java's built-in serialization mechanism (that's why it doesn't require Serializable, but accepts Object instead).

When I said "serialization", I was referring to the general process of serializing objects and was not specifically referring to Java's particular built-in mechanism. I am fully familar with JSON and can assure you that all of the JSON serializers I've worked with in Java use reflection internally to locate all of the object fields which need to be written out.

Some things have been marked deprecated and may not be part of the core JDK anymore, but everything is still available for the time being.

Like you said: "for the time being". Recent JDKs are spitting out increasingly unfriendly warnings like:

WARNING: An illegal reflective access operation has occurred
...
WARNING: Use --illegal-access=warn to enable warnings of further illegal reflective access operations
WARNING: All illegal access operations will be denied in a future release

which make it crystal clear where the JDK is headed. And some of these warnings are unfixable because we need access to those fields which have inconsiderately been declared "private".

Have fun writing your JSON serialization framework in Java when you cannot access your objects' internal states.

[bug77]

When I said "serialization", I was referring to the general process of serializing objects and was not specifically referring to Java's particular built-in mechanism. I am fully familar with JSON and can assure you that all of the JSON serializers I've worked with in Java use reflection internally to locate all of the object fields which need to be written out.

Now you're mixing things up. Built-in serialization is not used, but at the same time, reflection is not a must. Reflection is used because it was readily available (and doesn't totally kill performance), but you could use preprocessors just the same.

Like you said: "for the time being". Recent JDKs are spitting out increasingly unfriendly warnings like:

which make it crystal clear where the JDK is headed. And some of these warnings are unfixable because we need access to those fields which have inconsiderately been declared "private".

Have fun writing your JSON serialization framework in Java when you cannot access your objects' internal states.

Do you know of a cleaner way to move Java forward without having everyone use a JRE with lots of legacy technologies? Or are you complaining just because?

I'm guessing the answer was already apparent when you wrote "unfriendly warnings". I don't see those warnings as unfriendly, but rather like "oh, look, things have moved on since I wrote that piece of code". And I'm a big fan of moving code forward; as opposed to crying when a change in the underlying runtime even hints at me having to adjust it sometime in the future.

[sindr]

joosters from Hacker News writes:

Is it just me, or does all garbage collector development seem to go through an endless loop of:

* We've optimised this release for throughput

* We've optimised this release for latency

* We've optimised this release for minimising memory usage

...and each release causes a regression in the stuff they weren't optimising for, leading to another future release picking one of the other three targets.

Java and Go seem to have gone round this cycle more than once..