JIT stops compiling after a while (java 8u45)

Tobias Hartmann tobias.hartmann at oracle.com
Wed Mar 2 09:33:28 UTC 2016

Hi Uwe,

On 02.03.2016 10:08, Uwe Schindler wrote:
> Hi,
>>>> For real world applications I hope that this is a much smaller issue but if
>> you must load and execute loads and loads of short lived classes then it might
>> be reasonable to disable concurrent class unloading (at the cost of getting
>> serial Full gcs instead).
>>> Unfortunately, this is not a theoretical issue for us. We see this problem
>> running Presto (http://prestodb.io), which generates bytecode for every
>> query it processes. For now, we're working around it with a background
>> thread that watches the size of the code cache and calls System.gc() when it
>> gets close to the max
>> (https://github.com/facebook/presto/commit/91e1b3bb6bbfffc62401025a24
>> 231cd388992d7c).
>> Okay, I changed JDK-8023191 from enhancement to bug and set fix version to
>> 9. We can then backport this to 8u.
> Hi many thanks for taking care!
> Apache Lucene's Expressions module (heavily used by Elasticsearch) also compiles small Java classes to execute custom document scoring operations that the user can supply, similar to Presto's SQL, as a Javascript-like formula that can work on arbitrary static double-parameter/double returning functions. These classes are loaded in a separate ClassLoader used solely for a single class and thrown away afterwards. In older Java versions GC was perfectly throwing away those classes...
> Compiler & Classloader:
> https://github.com/apache/lucene-solr/blob/master/lucene/expressions/src/java/org/apache/lucene/expressions/js/JavascriptCompiler.java
> See tests like:
> https://github.com/apache/lucene-solr/tree/master/lucene/expressions/src/test/org/apache/lucene/expressions/js

Please note that JDK-8023191 only takes care of flushing of unused OSR nmethods. This should help if the code cache fills up due to OSR compilations but it's not about unloading of classes. Class unloading just helps because it forces flushing right away.

As Mikael wrote, unloading happens later with concurrent class unloading. This shouldn't be a problem for your application as long as the code cache does not fill up, right?

Best regards,

More information about the hotspot-compiler-dev mailing list