Hacker News Reader

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.

View on HN

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?

Not sure about jvisualvm, but it will definitely be visible in jconsole

jvisualvm is largely a superset of jconsole, with a plugin interface, so it probably is.

I have no idea how many other people actually use it though.

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

Reply on news.ycombinator.com