JIT stops compiling after a while (java 8u45)

Vitaly Davidovich vitalyd at gmail.com
Wed Mar 2 13:06:20 UTC 2016


On Wednesday, March 2, 2016, Uwe Schindler <uschindler at apache.org> wrote:

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

No loops means no OSR compilation of that bytecode but if it's called
millions of times (based on what you said above) then it'll get compiled.
It may be that your bytecode generates really small nmethods (you mentioned
it's simple algebraic expressions) and their generation naturally doesn't
outpace code cache cleaning.

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

-- 
Sent from my phone
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/hotspot-gc-dev/attachments/20160302/9175ecc7/attachment-0001.html>


More information about the hotspot-gc-dev mailing list