lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dawid Weiss <>
Subject Re: Long jenkins builds with clover/ code cache warning.
Date Fri, 20 Apr 2012 05:52:41 GMT
Just wanted to confirm my above suspicion about the code cache --
those long build times are fully repeatable on my machine (including
the time when code cache explodes). Timing from my machine for that
long test (when run in complete mode):

Completed in 3305.33s, 34 tests

The most recent build passed (with increased code cache threshold).


On Fri, Apr 20, 2012 at 1:05 AM, Dawid Weiss <> wrote:
> Oh, I just digested a spoonful of hotspot source code. It seems there
> is a magic option to attempt to clean the code cache before shutting
> down the compiler...
>  product(bool, UseCodeCacheFlushing, false,                            
>          "Attempt to clean the code cache before shutting off compiler")   \
> Unfortunately it's false by default...
> Dawid
> On Fri, Apr 20, 2012 at 12:45 AM, Dawid Weiss <> wrote:
>> So, for the past three or so hours I've been looking at this:
>> You'll notice that certain tests in there have super-long execution
>> times, like this one:
>>   [junit4] Suite:
>>   [junit4] Completed in 4251.28s, 34 tests
>> This test, if run separately, passes in under 60 seconds on my machine
>> (running with clover, the same seed so identical startup parameters
>> etc.).
>> I'll spare you the details but what seems to be happening is that at
>> some point the code cache is saturated and the JVM emits this:
>>   [junit4] OpenJDK 64-Bit Server VM warning: CodeCache is full.
>> Compiler has been disabled.
>>   [junit4] OpenJDK 64-Bit Server VM warning: Try increasing the code
>> cache size using -XX:ReservedCodeCacheSize=
>> Note the "Compiler has been disabled." bit. I believe this effectively
>> means the JVM falls back to interpreted mode (!) and this creates a
>> situation in which:
>> 1) there is a shitty random pick of components for the test (see
>> attached log dump),
>> 2) the code is instrumented with clover, which adds an extra layer of
>> super-overhead method calls and complexity,
>> 3) the JVM falls back to interpreted mode.
>> TestNumericRangeQuery64 is the first test when this hits, but every
>> test from that moment on is just sloooow. Like this one:
>>  [junit4] Suite: org.apache.lucene.index.TestDocTermOrds
>>  [junit4] Completed in 91.39s, 3 tests
>> ran separately (same seed, clover):
>>   [junit4] Suite: org.apache.lucene.index.TestDocTermOrds
>>   [junit4] Completed in 2.30s, 3 tests
>> I don't think there are simple solutions to this problem other than
>> setting a larger code cache (which I did, we will see).
>> Dawid

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message