Hacker News Reader

Comment by Animats | Hacker News Reader

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.

View on HN

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.

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

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.

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.

> You can have the same methods inlined in many places

Isn't the JVM more conservative about inlining already inlined methods? I can't find a cite right now, but I swear I've seen this when inspecting the compiler output.

yes, if the method was already compiled into a big or medium size method (in term of assembly code). JITs will not try to inline it again otherwise you will have too much code duplication and nobody want too many cache misses from the instruction cache.

Now that's something to look for. If something is generating code for each transaction, and that code shares a cache with other, more permanent code, cache thrashing is possible. If the cache management favors new code over old code, old code is likely to be pushed out as the cache fills up with query code. Then the old code gets recompiled the next time it's needed. Could that be why so much time is being spent in the JIT compiler?

Reply on news.ycombinator.com