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

[bug77]

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..

I think it's just him.
Unlike Go, Java's GC is very tunable. So each of those "we've optimized for..." lines should really read "we've set the GC defaults for...". No matter how the JRE is configured out-of-the-box, not only do you get to tune the GC in a million ways, you also have a couple more GCs to choose from.
Go, on the other hand, decided this is too much and went with the "one size fits all" approach. With all the benefits and drawbacks. One of the drawbacks being over there the defaults actually matter and they will hurt if/when they don't match what you need.

Garbage collectors being automated beasts, there will always be a use case that will bring out the worst in any implementation. Imho if your usage patterns are so wildly different that that cannot be accommodated by any combination of GC parameters, you've just picked the wrong tool/language for the job.

[chrisr]

Now you're mixing things up. Built-in serialization is not used, but at the same time, reflection is not a must.

I mixed nothing because I was never talking about "java.io.Serializable" - based serialization in the first place. That was 100% your own misunderstanding.

Reflection is used because it was readily available (and doesn't totally kill performance), but you could use preprocessors just the same.

Use a preprocessor at runtime? Really? By all means

T ObjectMapper.readValue(InputStream src, Class<T> valueType);
void ObjectMapper.writeValue(OutputStream dest, Object value);

Or are you complaining just because?

Actually I'm a long-standing real world Java developer who is trying to migrate a not-that-old code base from Java 8 to Java 11, and who is realising that modern JDKs are planning on bricking up my upgrade path.

So the JDK is moving forward "Full steam ahead!" and I'm saying ICEBERG! And you are saying "La-la-la-not-listening" from the top of your ivory tower.

[bug77]

I mixed nothing because I was never talking about "java.io.Serializable" - based serialization in the first place. That was 100% your own misunderstanding.


Use a preprocessor at runtime? Really? By all means

T ObjectMapper.readValue(InputStream src, Class<T> valueType);
void ObjectMapper.writeValue(OutputStream dest, Object value);

Actually I'm a long-standing real world Java developer who is trying to migrate a not-that-old code base from Java 8 to Java 11, and who is realising that modern JDKs are planning on bricking up my upgrade path.

So the JDK is moving forward "Full steam ahead!" and I'm saying ICEBERG! And you are saying "La-la-la-not-listening" from the top of your ivory tower.

What can I say, you're so seasoned, you're apparently unaware preprocessors work their magic at compile time. Lombok rings a bell?
JDK evolves. So does any living thing. Need I remind you what happens to those that do not adapt fast enough?

[chrisr]

What can I say, you're so seasoned, you're apparently unaware preprocessors work their magic at compile time. Lombok rings a bell?

Ah, you are apparently referring to an "annotation processor". My understanding of the term "preprocessor" is very different.

You are correct in that I have very little experience with annotation processors in general. The last time I looked at them they were used for generating the source code for stub classes.

[bug77]

Ah, you are apparently referring to an "annotation processor". My understanding of the term "preprocessor" is very different.

You are correct in that I have very little experience with annotation processors in general. The last time I looked at them they were used for generating the source code for stub classes.

Look at them closer. If Java is to move on from reflection, this is what is going to replace it. It's already in widespread use in microservices frameworks like Micronaut and Quarkus.
Whatever was traditionally done through reflection at runtime, these guys generate at compile time, basically, zeroing the runtime overhead. Of course, they'll never be able to do Class.forName("xxx") where xxx comes from a configuration and the actual class is obtained over the Internet at runtime, but other than that they're pretty capable.

Also, sorry for the terms mix-up. In my head annotation processing happening before the actual processing, made it a pre-processor. I forgot that also means other things. Sorry for the harsh language, too.

[chrisr]

Of course, they'll never be able to do Class.forName("xxx") where xxx comes from a configuration and the actual class is obtained over the Internet at runtime,...

Unfortunately, our use-case requires that we examine the runtime state of objects belonging to an arbitrary third party. And there's even some funky ClassLoader work in there too, along with a java agent which wants to rewrite some class byte-code on the-fly. We started developing this on Java 8 while Java 9 was still at the EAP stage - which was far, far too early for support from Gradle - and I honestly believe that we don't have a snowball's chance of running on a JVM which does not support reflection.

Also, sorry for the terms mix-up. In my head annotation processing happening before the actual processing, made it a pre-processor. I forgot that also means other things. Sorry for the harsh language, too.

Thank you for saying that .

[bug77]

Unfortunately, our use-case requires that we examine the runtime state of objects belonging to an arbitrary third party. And there's even some funky ClassLoader work in there too, along with a java agent which wants to rewrite some class byte-code on the-fly. We started developing this on Java 8 while Java 9 was still at the EAP stage - which was far, far too early for support from Gradle - and I honestly believe that we don't have a snowball's chance of running on a JVM which does not support reflection.

But reflection is still supported. It's just to be avoided if you want to use the native image feature of GraalVM. Even if you don't, developing with Micronaut/Quarkus without reflection and seeing the effects on startup performance and memory consumption is an eye opener.
But I'm with you, having no LTS JDK between 8 and 11 hurt Java big time. Big changes+nothing production ready=people staying away.