G1GC/ JIT compilation bug hunt.
dawid.weiss at gmail.com
Wed Aug 14 05:38:50 PDT 2013
Thanks Mikael. Limiting the assembly output is a good hint, I'll try
to reproduce it and see what happens.
On Wed, Aug 14, 2013 at 8:58 AM, Mikael Gerdin <mikael.gerdin at oracle.com> wrote:
> Hi Dawid,
> On 2013-08-14 08:27, Dawid Weiss wrote:
>> Hi everyone,
>> I am a committer to the Lucene/Solr project. We've recently hit what
>> we believe is a JIT/GC bug -- it manifests itself only when G1GC is
>> used, on a 32-bit VM:
>> Using Java: 32bit/jdk1.8.0-ea-b102 -server -XX:+UseG1GC
>> Java: 32bit/jdk1.7.0_25 -server -XX:+UseG1GC
>> Here is the Lucene issue where more information is available:
>> In the essence, the problem is that the code hits an assertion (in
>> Java) which it should never reach. There used to be a problem with our
>> implementation of readByte which tripped C2, but this was patched by
>> an alternate implementation a while back -- see here, line 97 (inside
>> This time it seems to be something else and is *not* easily
>> reproducible on a smaller example (it's not even reproducible on that
>> particular test all the time).
>> Is there anything you can think of that we can do and which would help
>> you in narrowing down what the problem might be? I initially thought
>> to pass -XX:+PrintCompilation -XX:+PrintAssembly but this will result
>> in a huge log as this happens some time in the middle of a test run
>> (and not always). If there's a shorter route I'd be happy to use it.
> If you have a guess about which method is mis-compiled you can try with
> -XX:CompileCommand="print org/apache/foo::method"
> This enables +PrintNMethods on a per-method basis.
> If you suspect several methods you can use CompileCommandFile and create a
> text file with several "print" commands.
> You also need to compile the hsdis disassembler library and place it in the
> jre/lib/i386 directory to get the actual output from
More information about the hotspot-dev