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

JVM JIT optimization techniques

advancedweb.hu

Post reply on HN
Print view View original

1–10 of 62 posts

Re: JVM JIT optimization techniques

#3

Post by userbinator »

for most of the time, many performance considerations are invisible from the higher abstraction levels, so you can concentrate writing simple, elegant and maintainable applications in Java, Scala, Kotlin or anything that runs on the JVM.

Funny statement, at least for Java. I don't know anyone who would say the majority of Java applications aren't huge, slow, memory-hogging beasts compared to equivalent native ones, and whose codebases are just as unoptimised for the perspective of the humans who have to work with them. That's mainly perception from when I briefly worked with Enterprise Java many years ago --- no one wrote "simple" or "elegant" Java applications, and stuffing as many design patterns and abstractions in as you could was considered "best practice".

There are certainly examples of simple and small Java applications (see https://en.wikipedia.org/wiki/Java_4K_Game_Programming_Conte... ), and I've written a few, but the overwhelming culture seems to be that of anti-optimisation and bureaucratic excess. In some sense, it's almost like working against or "challenging" the JVM's optimiser is the norm.

In my experience, a "simple, elegant" design --- which does not necessarily mean "highly abstract" --- tends to be very close to optimal anyway, with the compiler's optimiser doing the remaining work. That makes me wonder whether claiming a language/runtime/compiler has powerful optimisation abilities is actually a reflection of how much the typical source code in the language has to be "cleaned up" by the optimiser in order to be decently efficient.

Also, does anyone else notice the "Machine code" given for the JIT example is completely unrelated to either the Java or bytecode? It's 16-bit realmode --- I recognise the access to the 40h segment, it seems to be timing-related, and a bit of Googling finds that it's actually part of an old TSR clock utility (with unknown source):

http://assembly.happycodings.com/code24.html

Re: JVM JIT optimization techniques

#4

Post by zmmmmm »

It's interesting how most of the optimizations are only really available if you essentially write your programs in a functional style. That is, they all depend on the compiler being able to analyse the local scope to decide whether the state changes are confined enough that it can perform an optimization without changing behavior. If a reference escapes, even into a private, instance variable, the compiler will (admittedly, only based on the shallow analysis in this article), more or less give up, because it can't predict any more how that variable might be mutated from another scope.

Re: JVM JIT optimization techniques

#6

Post by bitmapbrother »

userbinator wrote: post #3

for most of the time, many performance considerations are invisible from the higher abstraction levels, so you can concentrate writing simple, elegant and maintainable applications in Java, Scala, Kotlin or anything that runs on the JVM. Funny statement, at least for Java. I don't know anyone who would say the majority of Java applications aren't huge, slow, memory-hogging beasts compared to equivalent native ones, a…

Ah, the Java is slow argument. When were you doing Enterprise Java? It must have been around the pre HotSpot years.

As for applications that are huge, memory hogs, complex and non elegant, well, congratulations you just described the majority of enterprise applications.

Re: JVM JIT optimization techniques

#8

Post by jsnell »

orf wrote: post #2

There is something about this site that absolutely destroys Firefox when scrolling. Expensive work in a scroll handler isn't good guys :(

I would not be too quick to blame the authors of the website. It seems likely to be the same Firefox bug as all the other cases of HN comments complaining about bad scrolling performance in Firefox: https://bugzilla.mozilla.org/show_bug.cgi?id=1250947

Re: JVM JIT optimization techniques

#9

Post by NotRustAgain »

bitmapbrother wrote: post #6
userbinator wrote: post #3

for most of the time, many performance considerations are invisible from the higher abstraction levels, so you can concentrate writing simple, elegant and maintainable applications in Java, Scala, Kotlin or anything that runs on the JVM. Funny statement, at least for Java. I don't know anyone who would say the majority of Java applications aren't huge, slow, memory-hogging beasts compared to equivalent native ones, a…

Ah, the Java is slow argument. When were you doing Enterprise Java? It must have been around the pre HotSpot years. As for applications that are huge, memory hogs, complex and non elegant, well, congratulations you just described the majority of enterprise applications.

https://benchmarksgame.alioth.debian.org/u64q/java.html

Consistently twice as slow, with memory usage between 2 and 400(!) times larger. Java is slow and bloated compared to native.

Your next argument will be something about how micro-benchmarks don't reflect reality for larger programs...

Re: JVM JIT optimization techniques

#10

Post by LnxPrgr3 »

orf wrote: post #2

There is something about this site that absolutely destroys Firefox when scrolling. Expensive work in a scroll handler isn't good guys :(

I loaded this in Firefox on a Raspberry Pi 3 (don't ask), and never got to see below the fold--burned CPU for a minute or two before I gave up and closed it. I had pressed page-down once--don't know if it ever got around to processing the scroll event.

Don't know the root cause, but the worst most sites get on here is annoyingly sluggish. Between the site and Firefox, something's definitely triggering pathological behavior.

Post reply on HN