JRE 8 needs more codecache than before

Typical problem of over tuning. Not every tunable needs to be tweaked (or worse cut&#x27;n&#x27;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.<p>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.

To the author: It would be useful to put a little blurb paragraph at the top to say that if you haven&#x27;t overridden the default codecache size via JVM options, no action is necessary. This information is buried way down at the bottom of the page, which may lead hurried readers to assume that something may already be wrong with their Java 8 JVMs.

Would a good approach to major JVM upgrades in production be to remove all but critical JVM flags in the new version, and run it on a subset of nodes, then?<p>After getting a baseline measurement of performance with JVM defaults, experiment with tuning a couple of settings, measure some more, make sure nothing breaks under load. Repeat until new JVM version seems stable&#x2F;performs better&#x2F;etc even under worst load and then upgrade all nodes to the latest and greatest?

I wonder how many projects have production issues because they are not able to hit expected production volume in a QA environment? This is certainly the cause of a lot of grief I&#x27;ve experienced.

How much Java source code does it take to need 256MB of codecache? The author says they&#x27;re using a service architecture where each transaction uses about 20 services. There&#x27;s no indication of why their program is so huge.

so the unspoken thing seems to be that they kept the same JVM arguments as java 7 and that caused problems in java 8? and they had a JVM argument that was setting a value to the same as the default?

-XX:-TieredCompilation is the magic option to disable tiered compilation.<p>Beginning with Java 8, instead of having the VM to magically choose between using the client JIT (c1: think V8) or the server JIT (c2: think gcc -O2), the default configuration is to run in so called &quot;tiered mode&quot;, first starts with the interpreter (as usual) then c1 (here keep the profile info) then c2. Because the code is compiled twice, you need a twice bigger code cache.<p>From my own experience, tiered compilation is nice when you run something interactive like an IDE (IntelliJ IDEA) and useless when you run a server app. That&#x27;s said i&#x27;ve never had to have a 250MB code cache.

If the JVM has one bytecode compiler that it uses only during startup and another that it used the rest of the time, shouldn&#x27;t it dump the bytecode generated by the first compiler from the cache at the point when it switches to the second compiler?

Yikes ! Can somebody with deep AWS knowledge comment on how this impacts aws lambda (java) and AWS Elastic beanstalk applications? what configuration is recommended?