JIT stops compiling after a while (java 8u45)
tobias.hartmann at oracle.com
Wed Mar 2 09:33:28 UTC 2016
On 02.03.2016 10:08, Uwe Schindler wrote:
>>>> 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
>> 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!
> Compiler & Classloader:
> See tests like:
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?
More information about the hotspot-gc-dev