Live data from Hacker News

JRE 8 needs more codecache than before

engineering.indeedblog.com

11–20 of 38 posts

Re: JRE 8 needs more codecache than before

#11

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've experienced.

For us, it's not production volumes that are the main issue but production dynamics i.e. how the volumes change over time. It's such a big issue that standard practice is to run QA against live production data by default and manage the consequences.

The downside is, when we do need to use test data e.g. when there's a large change to the structure of the upstream or we want to do stress scenarios, it's a pain in the backside.

Re: JRE 8 needs more codecache than before

#13
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.

Re: JRE 8 needs more codecache than before

#14

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

Code is sometimes un-optimised, presumably the best option is to go back to lightly-compiled.

Re: JRE 8 needs more codecache than before

#15

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've experienced.

For us, it's not production volumes that are the main issue but production dynamics i.e. how the volumes change over time. It's such a big issue that standard practice is to run QA against live production data by default and manage the consequences. The downside is, when we do need to use test data e.g. when there's a large change to the structure of the upstream or we want to do stress scenarios, it's a pain in the…

We struggle with this too. There are so many ways the dynamics can change--daily/weekly/seasonal cycles, robots, client caching, etc. One best practice we use for high-volume services is to minimize the variance in call mixtures--if there are two calls with vastly different call patterns, it's probably worth it to split them into separate services, so you can tune throttling, GC, load balancing, etc. specifically for those calls, instead of having to tune them to support both calls (which is often difficult or impossible to do). Of course, it's hard to predict how your service will evolve over time, so making the split is often painful for you and your clients. Some of our services can't be handled by a single load balancer, so we use DNS round robins, which have a whole other class of problems when you have mixed call patterns. Gotta earn your pay...

Some other techniques we use are one-box deployments that receive a proportion of production traffic and "bake" new changes before deploying to the whole fleet, and shadow fleets which let you tune and test against live traffic. We've found that simply replaying production traffic at higher volumes sometimes isn't sufficient, because our calls don't necessarily scale that way (some of them scale with upstream traffic, some of them scale by downstream fleet sizes due to client caching).

Re: JRE 8 needs more codecache than before

#16
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?

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/performs better/etc even under worst load and then upgrade all nodes to the latest and greatest?

Re: JRE 8 needs more codecache than before

#17

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? 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/performs better/etc even under worst load and the…

Yes, I think that approach would avoid propagating inappropriate or unnecessary settings.

Re: JRE 8 needs more codecache than before

#18
post #4

How 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 f…

I for one would love to see the relationship between program size and code cache size on real applications.

Re: JRE 8 needs more codecache than before

#19
To the author: It would be useful to put a little blurb paragraph at the top to say that if you haven'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.

Re: JRE 8 needs more codecache than before

#20

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

I think you meant the machine code. The Java compiler produces bytecode from Java source. The C1 and C2 bytecode compilers in the JVM convert bytecode to machine code.

Yes, I agree if C2 recompiles something C1 already compiled, the C1-compiled machine code should be freed from the codecache.

Post reply on HN