Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Continuous delivery makes JVM JIT an anti-pattern

blog.astradot.com

Post reply on HN
Print view View original

31–37 of 37 posts

Re: Continuous delivery makes JVM JIT an anti-pattern

#31

Post by kimi »

xg15 wrote: post #19
tom_mellior wrote: post #15

> Production Java apps also typically run with APM tracing agents that rely on runtime bytecode instrumentation. [...] It is easier to start afresh with modern compiled languages like Go and Rust. I wonder how they instrument their Go and Rust programs. If they decide not to, maybe it's not that important for the Java version of the same code either.

No idea if this is done, but couldn't you in theory add the instrumentation before or during the compilation? Something like a tool that runs as part of the build process and modifies the source code before it gets passed to the compiler.

I'll take mature instrumentation that comes in the box and is a major design goal, meant to be transparently run in production (JVM, BEAM...) against anything you can do in Go.

Re: Continuous delivery makes JVM JIT an anti-pattern

#32

Post by tom_mellior »

blakehaswell wrote: post #24
tom_mellior wrote: post #16

Earlier quoted context omitted.

> It was always a dumb choice to make member functions default to virtual semantics, when they almost always don't need it, and it just costs performance to no purpose. If you actually don't need it (i. e., your hot methods are never overridden), then the JIT will trivially compile those "virtual" method calls as non-virtual ones. It has all the information it needs, since it knows what classes are loaded. It can inv…

> If you actually don't need it (i. e., your hot methods are never overridden), then the JIT will trivially compile those "virtual" method calls as non-virtual ones. But isn't that the thrust of this article? Of course the JIT can optimise a monomorphic call-site. The question is, in reality, what percentage of the time will it be optimised for your users?

What the article doesn't acknowledge is that there are many ways to force compilation of your code. You can change the threshold for the number of executions before the JIT is called. You can run scripts as part of your deployment that exercise the paths you are interested in. So yes, it's true that "this code runs very infrequently, but I still care about its latency" is not what JVMs might be optimized towards. But it's possible to understand the issues and solve them.

Re: Continuous delivery makes JVM JIT an anti-pattern

#33

Post by ncmncm »

tom_mellior wrote: post #32
blakehaswell wrote: post #24

Earlier quoted context omitted.

> If you actually don't need it (i. e., your hot methods are never overridden), then the JIT will trivially compile those "virtual" method calls as non-virtual ones. But isn't that the thrust of this article? Of course the JIT can optimise a monomorphic call-site. The question is, in reality, what percentage of the time will it be optimised for your users?

What the article doesn't acknowledge is that there are many ways to force compilation of your code. You can change the threshold for the number of executions before the JIT is called. You can run scripts as part of your deployment that exercise the paths you are interested in. So yes, it's true that "this code runs very infrequently, but I still care about its latency" is not what JVMs might be optimized towards. But…

To need to understand and solve issues is always worse than not to need either.

Java got commercial success despite its many design flaws, not because of them. $1B+ promotion from Sun helped some, providing a route to freedom from Microsoft sharecropping helped more.

Re: Continuous delivery makes JVM JIT an anti-pattern

#35

Post by pjmlp »

ncmncm wrote: post #33
tom_mellior wrote: post #32

Earlier quoted context omitted.

What the article doesn't acknowledge is that there are many ways to force compilation of your code. You can change the threshold for the number of executions before the JIT is called. You can run scripts as part of your deployment that exercise the paths you are interested in. So yes, it's true that "this code runs very infrequently, but I still care about its latency" is not what JVMs might be optimized towards. But…

To need to understand and solve issues is always worse than not to need either. Java got commercial success despite its many design flaws, not because of them. $1B+ promotion from Sun helped some, providing a route to freedom from Microsoft sharecropping helped more.

And from being way better than either C or C++ to write distributed applications.

Having done that with C across the major UNIX flavours around 2000 and later again with C++ and CORBA a couple of years later, it is kind of obvious why most enterprises moved into it (and its nemesis, .NET).

Re: Continuous delivery makes JVM JIT an anti-pattern

#36

Post by kaba0 »

filereaper wrote: post #4

>Molding a 25 year old runtime ecosystem to adapt to AOT compilation feels like putting lipstick on a pig. Other JVMs like J9 have had AOT support for decades now, its not "lipstick on a pig". There's plenty of material from previous JVMLS meetups about AOT.

Also, AOT support in itself is not hard. Making it performant is more difficult and Graal is truly remarkable/state of the art in many regards.

Re: Continuous delivery makes JVM JIT an anti-pattern

#37

Post by kaba0 »

blakehaswell wrote: post #24
tom_mellior wrote: post #16

Earlier quoted context omitted.

> It was always a dumb choice to make member functions default to virtual semantics, when they almost always don't need it, and it just costs performance to no purpose. If you actually don't need it (i. e., your hot methods are never overridden), then the JIT will trivially compile those "virtual" method calls as non-virtual ones. It has all the information it needs, since it knows what classes are loaded. It can inv…

> If you actually don't need it (i. e., your hot methods are never overridden), then the JIT will trivially compile those "virtual" method calls as non-virtual ones. But isn't that the thrust of this article? Of course the JIT can optimise a monomorphic call-site. The question is, in reality, what percentage of the time will it be optimised for your users?

You can even aot compile a class and have the cached “JIT compiled” code loaded on startup.

https://docs.oracle.com/en/java/javase/13/docs/specs/man/jao...

Post reply on HN