JRE 8 needs more codecache than before

Post by zigzigzag » Thu, Sep 15, 2016, 5:22 PM UTC

nn3 wrote: post #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 al…

Post by uxcn » Thu, Sep 15, 2016, 5:59 PM UTC

remh wrote: post #21

billsmithaustin wrote: post #5

Earlier quoted context omitted.

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…

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.

Post by jdmichal » Thu, Sep 15, 2016, 6:49 PM UTC

bobbyi_settv wrote: post #12

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?

    function doStuff(MyInterface a) {
        if (a.getClass() != MyClass.class)
            deoptimize();

        // Do everything from here on assuming
        // that a is an instance of MyClass.
        // This includes inlining simple getter
        // methods to pure field accesses, etc.
    }

Post by __-X-__ » Thu, Sep 15, 2016, 7:00 PM UTC

billsmithaustin wrote: post #20

bobbyi_settv wrote: post #12

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 by __-X-__ » Thu, Sep 15, 2016, 7:07 PM UTC

hyperpape wrote: post #23

electrum wrote: post #8

Earlier quoted context omitted.

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…

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