JRE 8 needs more codecache than before
engineering.indeedblog.com
JRE 8 needs more codecache than before
1–10 of 38 posts
Re: JRE 8 needs more codecache than before
#2so 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?
Re: JRE 8 needs more codecache than before
#3I 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've experienced.
Re: JRE 8 needs more codecache than before
#4How much Java source code does it take to need 256MB of codecache? The author says they're using a service architecture where each transaction uses about 20 services. There's no indication of why their program is so huge.
Re: JRE 8 needs more codecache than before
#5How much Java source code does it take to need 256MB of codecache? The author says they're using a service architecture where each transaction uses about 20 services. There's no indication of why their program is so huge.
Author here. We know 128MB codecache was not enough and 256MB was sufficient. I think we could have gotten by with less, e.g. 200MB, but we stopped experimenting once we found a value that worked.
We don't have a complete understanding of why this app uses so much more codecache than other apps we've switched to Java 8. Now that we expose the codecache size in Datadog, I may try plotting code size vs codecache size for a variety of our apps.
Re: JRE 8 needs more codecache than before
#6Yikes ! Can somebody with deep AWS knowledge comment on how this impacts aws lambda (java) and AWS Elastic beanstalk applications? what configuration is recommended?
Re: JRE 8 needs more codecache than before
#7so 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?
We knew to adjust other JVM settings (e.g. PermGen replaced by Metaspace) but we overlooked that (1) we used a non-default max codecache size and (2) the default for that setting was 3x higher for Java 8.
An unfortunate thing about using non-default JVM settings is that you need to scrutinize them every time you switch Java versions. If I ever go through this again, I will know to pay more attention to every JVM setting we override.
Re: JRE 8 needs more codecache than before
#8How much Java source code does it take to need 256MB of codecache? The author says they're using a service architecture where each transaction uses about 20 services. There's no indication of why their program is so huge.
Codecache is for compiled code, so it doesn't necessarily correlate to the original program's source code size. You can have the same methods inlined in many places, load the same classes in multiple class loaders (which means they are separate classes to the JVM), generate code at runtime, etc.
For example, Presto is a SQL query engine that generates code for each query (a SQL query is effectively a program), so it can need a lot of codecache depending on the query rate and concurrency.
Re: JRE 8 needs more codecache than before
#9Yikes ! Can somebody with deep AWS knowledge comment on how this impacts aws lambda (java) and AWS Elastic beanstalk applications? what configuration is recommended?
To be clear, the Java 8 default is much higher than Java 7's. If you stick with the default, you will probably be fine.
Re: JRE 8 needs more codecache than before
#10so 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?
We knew to adjust other JVM settings (e.g. PermGen replaced by Metaspace) but we overlooked that (1) we used a non-default max codecache size and (2) the default for that setting was 3x higher for Java 8. An unfortunate thing about using non-default JVM settings is that you need to scrutinize them every time you switch Java versions. If I ever go through this again, I will know to pay more attention to every JVM sett…
ah, so you had tuned JRE7 to use 64mb code cache (more than default), when then became far less than the new default.