A pretty good tale of debugging, but one thing I didn’t see mentioned is why they changed the code cache size in the first place. Java 8 appears to do the right thing here, increasing the default, but if you force it to use less memory, it runs poorly. So I think the lesson is don’t fiddle with knobs. I’ve seen other performance tuning guides that actually detune systems because the setting supposedly being raised is being lowered.
I also noticed that in LaTeX typesetting. Many people go out of their way to customize everything, but I noticed that going with the defaults often times yields much better results. For instance, leaving a blank page between chapters might look strange in the PDF output, but looks really good in print.
I’ve seen this too, also with Java: micro-managed memory & GC settings for a particular application cargo-culted to other services where they do more harm than good.
What’s really fun is when the cargo culting is so clearly misunderstood as to lead to impossibly broken configurations. I had a team that set the max and min heap sizes to 2GB… then attempted to run their application in a Docker container with a 1GB limit.
Knobs are for knobs.
It was pretty common to do that in Java 7, to give more memory to the application.
I’d also say it’s pretty common to confront a raft of -X options in your startup script, each accumulated over the years with no comments on why they’re present or what problem they once solved.
Btw, you can write story text on stories you posted. You don’t need to create a separate comment.
I believe that the submission text is to increase the quality of the submission. You cannot reply to it or vote on it.
Yeah, I’d use story text if the headline is vague or if there are more resources, or occasionally a tl;dr for the longest posts. For my own thinkies on a post I’m OP on, I’d use comments.
When submitting a URL, the text field is optional and should only be used when additional context or explanation of the URL is needed. Commentary or opinion should be reserved for a comment, so that it can be voted on separately from the story.
On the other hand, it’s possible that in v1 you have to fiddle with a knob to get decent performance for a specific usecase, and that in v2 any manual fiddling you’ve done in v1 is definitely not enough for some new feature, as appears to have happened here; and there’s no defense against that.
If I read this right, the default in JRE 7 was 48MB and they’d raised their it to 64MB. Presumably they originally measured the impact of code cache size on throughput on JRE7 and decided to add that number to increase it. Because that cache size was set to an absolute quantity and the default changed, they went from being at 133⅓% of the default to being at 50% of the default, and it thrashed.