Hacker News Reader

Comment by nn3 | Hacker News Reader

Typical problem of over tuning. Not every tunable needs to be tweaked (or worse cut'n'pasted somewhere from the internet). Your street cred as a admin does not depend on how many settings you can change. If they had just kept using the defaults everything would have been fine.

That said 250MB is really a lot of code. Their binaries must be gigantic. This by itself likely already causes performance problems because all caches will be thrashing.

View on HN

Yes but he said it was previously only 50mb. That 250mb contains a lot of duplicated compiles: tiered compilation can generate not just two but up to I think 5 different compiles of the same methods! I think code cache management in Hotspot is not that great: eventually the server would probably converge on a bit higher than 50mb due to the more aggressive inlining, but 5x suggests the low value compiles aren't being properly discarded.

It's all about the tiered compilation. Tons of unused but eagerly compiled code w/ C1 (the dumb and fast compiler) that never reached the proper C2.

The issue has been three since 6.0.23 when the -XX:+TieredCompilation defaulted to true. (hmm, or was it 6.0.25?)

I'd say nothing really new. If you run a server, just disable tired compilation altogether. It might cost few seconds slower startup but that's it.

I believe TieredCompilation was disabled by default on Java 7u55:

    $ java -server -XX:+UnlockDiagnosticVMOptions -XX:+PrintFlagsFinal -version|grep TieredCompilation
         bool TieredCompilation                         = false           {pd product}        
    java version "1.7.0_55"
    Java(TM) SE Runtime Environment (build 1.7.0_55-b13)
    Java HotSpot(TM) 64-Bit Server VM (build 24.55-b03, mixed mode)

I would be interested in hearing from people with first-hand experience disabling TieredCompilation on Java 8 on production servers.

Reply on news.ycombinator.com