JIT stops compiling after a while (java 8u45)

Uwe Schindler uschindler at apache.org
Wed Mar 2 10:03:23 UTC 2016

Hi Tobias,

> >>>> 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/expressi
> ons/js/JavascriptCompiler.java
> >
> > See tests like:
> > https://github.com/apache/lucene-
> solr/tree/master/lucene/expressions/src/test/org/apache/lucene/expressio
> ns/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.

Thanks! This is how it was designed: The classloader only lives for very short time and the compiled expression gets thrown away after fulltext query execution. This works quite good. I just have seen the issue on this mailing list and I wanted to start some test with recent Java 8 VMs if everything is still alright.

Martin Traverso's post alarmed me, because he said that they generate bytecode for every query (which is similar in our case). The main difference is: Our compiled methods are just plain simple mathematical formulas which are represented to the caller by a functional interface. We have no loops in the generated bytecode. The Lucene scoring algorithm just calls the compiled expression bytecode while processing results to calculate score (and depending on the number of search engine results collected, this can be several million times per query execution).

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

As said before, it should not fill up - as we have no loops in those expressions. I was just alarmed and wanted to start testing. We checked the whole stuff with Java 6 and Java 7 (when it was written), but have not done extensive testing of garbage collection with Java 8. But there were also no bug reports...

> Best regards,
> Tobias


More information about the hotspot-compiler-dev mailing list