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 <[email protected]> wrote:
> So, for the past three or so hours I've been looking at this:
>
> https://builds.apache.org/job/Lucene-Trunk/1899/consoleText
>
> You'll notice that certain tests in there have super-long execution
> times, like this one:
>
> [junit4] Suite: org.apache.lucene.search.TestNumericRangeQuery64
> [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: [email protected]
For additional commands, e-mail: [email protected]
