31–38 of 38 posts
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.
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 al…
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.
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 al…
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.
$ 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)
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…
Most of the settings found in legacy projects or on the internet are either obsolete or defaults in the latest version of the JVM.
The only mandatory heap flag is: "-Xms???M -Xmx???M" which set the heap size of the application to ??? megabytes.
Earlier quoted context omitted.
Datadog employee here, you don't need to run your own collector to collect codecache usage. As it's exposed through JMX, the JMX collector can collect it http://docs.datadoghq.com/integrations/java/ . It doesn't by default though, so you'll need to configure it to collect the metrics from the "java.lang:name=Code Cache,type=MemoryPool" bean. We should add that in our default configuration.
If it's exposed through JMX, would it also be visible via something like jvisualvm ?
Earlier quoted context omitted.
If it's exposed through JMX, would it also be visible via something like jvisualvm ?
Not sure about jvisualvm, but it will definitely be visible in jconsole
I have no idea how many other people actually use it though.
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. The good approach when you're given a legacy java application with tons of flags is to removed ALL the optimizations flags for the heap and the GC. Most of the settings found in legacy projects or on the internet are either obsolete or defaults in the latest version of the JVM. The only mandatory heap flag is: "-Xms???M -Xmx???M" which set the heap size of the application to ??? megabytes.
Earlier quoted context omitted.
Yes. The good approach when you're given a legacy java application with tons of flags is to removed ALL the optimizations flags for the heap and the GC. Most of the settings found in legacy projects or on the internet are either obsolete or defaults in the latest version of the JVM. The only mandatory heap flag is: "-Xms???M -Xmx???M" which set the heap size of the application to ??? megabytes.
Not even -Xms -Xmx, there's heuristics built in to appropriately size the gc spaces... http://hg.openjdk.java.net/jdk8/jdk8/hotspot/file/tip/src/sh...
It's only the server apps running 24/7 on fixed hardware that should have a defined memory usage.