7 ms·

JVM JIT optimization techniques

112 points by sashee 10y ago

orf 10y ago
There is something about this site that absolutely destroys Firefox when scrolling. Expensive work in a scroll handler isn't good guys :(
- jsnell 10y ago
  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 https://bugzilla.mozilla.org/show_bug.cgi?id=1250947
  - pygy_ 10y ago
    Bad link, I'm afraid... It's about a box-shadow glitch.
    - jsnell 10y ago
      It's the correct link (if you read the last 15 or so comments, it'll be more obvious that there is a performance component to the issue).
      - mediumdeviation 10y ago
        It seems you're correct. Specifically, disabling this rule from the inspector instantly fixes the performance issue. .widewrapper.main { box-shadow: inset 1px 3px 1px -2px #ababab; }
- harlowja 10y ago
  Same for me; 46.0.1 windows 7 (if authors care to reproduce).
- fspoon 10y ago
  Page pinwheels on load for me (FF 46.0.1), OSX
- sashee 10y ago
  Wow, it is indeed slow on Firefox! Thanks for letting us know, we both test on Chrome so we didn't notice the problem. We'll look into it.
- LnxPrgr3 10y ago
  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.
- anglebracket 10y ago
  As a workaround you can go to "View > Page Style > No style". It honestly reads just fine without CSS.
  - mineo 10y ago
    Or use the reader view.
userbinator 10y ago
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_Contest 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 http://assembly.happycodings.com/code24.html
- bitmapbrother 10y ago
  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.
  - NotRustAgain 10y ago
zmmmmm 10y ago
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.
- pron 10y ago
  That's not a functional style, but an observation of how most (non-pathological) code behaves. If you're talking about escape analysis and stack allocation, the functional style doesn't help, because references escape all the time. That they're pointing to immutable objects doesn't matter. In any case, whether functional or not, the observation is that many objects have limited scopes, that correspond to structural scopes in the code.
  - merb 10y ago
    Actually In all analysis seen so far it mostly is way slower to do the Java EE style (biomorphic, megamorphic) and instead use normal classes, static class functions instead of polymophism. So actually a flat level is way faster than any sane stuff which is mostly done in a lot of Enterprise software.
- Alphasite_ 10y ago
  Escape analysis is pretty damn capable if you can give it enough time to run.
  - laerad 10y ago
    The analysis is fine, but "escape analysis" is often conflated with stack allocation, and at this hotspot is actually really terrible. The constraints on allocating to the stack mean it happens very infrequently, even if the literal escape analysis would permit it otherwise.
karankamath 10y ago
Maybe a noob observation, but can anyone explain why the Lock Coarsening example is valid? Seems to me that locks on A with a lock on B in between is not equivalent to 2 locks on A and then one on B... Unless the programmer made a cognitive error the cases seem incomparable, unlike the other examples.
- taspeotis 10y ago
  "Seems to me that locks on A with a lock on B in between is not equivalent to 2 locks on A and then one on B" You're looking at: public void canNotBeMerged() The locks can't be merged.
  - karankamath 10y ago
    Yeah, but the semantics there refer to merged by an optimization? What's the point of having incomparable examples?
    - Alphasite_ 10y ago
      Just to demonstrate an example of invalid code?

112 points by sashee 10y ago

orf 10y ago

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

jsnell 10y ago
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 https://bugzilla.mozilla.org/show_bug.cgi?id=1250947
- pygy_ 10y ago
  Bad link, I'm afraid... It's about a box-shadow glitch.
  - jsnell 10y ago
    It's the correct link (if you read the last 15 or so comments, it'll be more obvious that there is a performance component to the issue).
    - mediumdeviation 10y ago
      It seems you're correct. Specifically, disabling this rule from the inspector instantly fixes the performance issue. .widewrapper.main { box-shadow: inset 1px 3px 1px -2px #ababab; }
harlowja 10y ago
Same for me; 46.0.1 windows 7 (if authors care to reproduce).
fspoon 10y ago
Page pinwheels on load for me (FF 46.0.1), OSX
sashee 10y ago
Wow, it is indeed slow on Firefox! Thanks for letting us know, we both test on Chrome so we didn't notice the problem. We'll look into it.
LnxPrgr3 10y ago
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.
anglebracket 10y ago
As a workaround you can go to "View > Page Style > No style". It honestly reads just fine without CSS.
- mineo 10y ago
  Or use the reader view.

userbinator 10y ago

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_Contest 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 http://assembly.happycodings.com/code24.html

bitmapbrother 10y ago
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.
- NotRustAgain 10y ago

zmmmmm 10y ago

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.

pron 10y ago
That's not a functional style, but an observation of how most (non-pathological) code behaves. If you're talking about escape analysis and stack allocation, the functional style doesn't help, because references escape all the time. That they're pointing to immutable objects doesn't matter. In any case, whether functional or not, the observation is that many objects have limited scopes, that correspond to structural scopes in the code.
- merb 10y ago
  Actually In all analysis seen so far it mostly is way slower to do the Java EE style (biomorphic, megamorphic) and instead use normal classes, static class functions instead of polymophism. So actually a flat level is way faster than any sane stuff which is mostly done in a lot of Enterprise software.
Alphasite_ 10y ago
Escape analysis is pretty damn capable if you can give it enough time to run.
- laerad 10y ago
  The analysis is fine, but "escape analysis" is often conflated with stack allocation, and at this hotspot is actually really terrible. The constraints on allocating to the stack mean it happens very infrequently, even if the literal escape analysis would permit it otherwise.

karankamath 10y ago

Maybe a noob observation, but can anyone explain why the Lock Coarsening example is valid? Seems to me that locks on A with a lock on B in between is not equivalent to 2 locks on A and then one on B... Unless the programmer made a cognitive error the cases seem incomparable, unlike the other examples.

taspeotis 10y ago
"Seems to me that locks on A with a lock on B in between is not equivalent to 2 locks on A and then one on B" You're looking at: public void canNotBeMerged() The locks can't be merged.
- karankamath 10y ago
  Yeah, but the semantics there refer to merged by an optimization? What's the point of having incomparable examples?
  - Alphasite_ 10y ago
    Just to demonstrate an example of invalid code?