RFR(S): 8134468: Lucene test failures with 32 bit JDK 9b78, Server compiler

[Uwe Schindler]

I got another failure with exactly same code:

http://jenkins.thetaphi.de/job/Lucene-Solr-trunk-Linux/14421/

So it is definitely reproducible. I was not yet able to reproduce it or test your patch (I have not much experience in doing this). Maybe Dawid Weiss has some time to try it out.
I just wanted to let you know that it is reproducible. The above Jenkins link allows to download hserr.pid and replay logs, too.

Uwe

-----
Uwe Schindler
uschindler at apache.org 
ASF Member, Apache Lucene PMC / Committer
Bremen, Germany
http://lucene.apache.org/


> -----Original Message-----
> From: Roland Westrelin [mailto:roland.westrelin at oracle.com]
> Sent: Monday, October 05, 2015 11:55 AM
> To: Uwe Schindler
> Cc: hotspot-compiler-dev at openjdk.java.net
> Subject: Re: RFR(S): 8134468: Lucene test failures with 32 bit JDK 9b78, Server
> compiler
> 
> > Do you know when the fix for JDK-8134974 is included in EA builds? If yes,
> maybe we first try to check if it's already fixed.
> 
> b84 it seems.
> 
> You could try to apply the fix, it’s small:
> 
> http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/bfb61f868681
> 
> Or we can wait until b84 is out and see if it’s still there.
> 
> Roland.
> 
> >
> > Uwe
> >
> > -----
> > Uwe Schindler
> > uschindler at apache.org
> > ASF Member, Apache Lucene PMC / Committer Bremen, Germany
> > http://lucene.apache.org/
> >
> >
> >> -----Original Message-----
> >> From: Roland Westrelin [mailto:roland.westrelin at oracle.com]
> >> Sent: Monday, October 05, 2015 11:01 AM
> >> To: Uwe Schindler
> >> Cc: hotspot-compiler-dev at openjdk.java.net
> >> Subject: Re: RFR(S): 8134468: Lucene test failures with 32 bit JDK
> >> 9b78, Server compiler
> >>
> >> Uwe,
> >>
> >>> Thanks. I was trying b82 yesterday and we already found a new bug.
> >>> Tests
> >> were failing with SIGSEGV on Jenkins:
> >>> http://jenkins.thetaphi.de/job/Lucene-Solr-5.x-Linux/14121/
> >>> (you can download "hs_err" and "replay" from there, you can also see
> >>> JVM
> >> settings like bitness, Garbage Collector from there).
> >>
> >> Thanks for reporting this new issue.
> >>
> >>>
> >>> Current CompileTask:
> >>> C2: 866319 28632       4
> >> org.apache.directory.api.ldap.model.name.Rdn::apply (45 bytes)
> >>>
> >>> Stack: [0x00007f3e647e6000,0x00007f3e648e7000],
> >>> sp=0x00007f3e648e1e60,  free space=1007k Native frames: (J=compiled
> >>> Java code, j=interpreted, Vv=VM code, C=native code) V
> >>> [libjvm.so+0x80ccce]
> >>> PhaseIdealLoop::build_loop_late_post(Node*)+0x13e
> >>> V  [libjvm.so+0x80d06b]  PhaseIdealLoop::build_loop_late(VectorSet&,
> >>> Node_List&, Node_Stack&)+0x13b V  [libjvm.so+0x8102dc]
> >>> PhaseIdealLoop::build_and_optimize(bool, bool)+0x88c V
> >>> [libjvm.so+0x4e699a]  Compile::Optimize()+0x6ca V
> >>> [libjvm.so+0x4e83f0]  Compile::Compile(ciEnv*, C2Compiler*,
> >>> ciMethod*, int, bool, bool, bool)+0x1040 V  [libjvm.so+0x42dbb9]
> >>> C2Compiler::compile_method(ciEnv*, ciMethod*, int)+0xe9 V
> >>> [libjvm.so+0x4effda]
> >>> CompileBroker::invoke_compiler_on_method(CompileTask*)+0x8ca
> >>> V  [libjvm.so+0x4f0a58]  CompileBroker::compiler_thread_loop()+0x4a8
> >>> V  [libjvm.so+0xa61038]  JavaThread::thread_main_inner()+0xd8
> >>> V  [libjvm.so+0xa611d8]  JavaThread::run()+0x158 V
> >>> [libjvm.so+0x9048e2]  java_start(Thread*)+0xc2 C
> >>> [libpthread.so.0+0x8182]  start_thread+0xc2
> >>>
> >>> siginfo: si_signo: 11 (SIGSEGV), si_code: 1 (SEGV_MAPERR), si_addr:
> >>> 0x0000000000000008
> >>>
> >>>
> >>> This happened in parallel for 2 different JVMs (we are running tests
> >>> in
> >> parallel with multiple JVMs). We should look into this, too! Tell me
> >> how I can help (as always, it is hard to reproduce). So this must be
> >> some change between b78 and b82 (b78 is last known working config).
> >> Maybe bells are ringing for you.
> >>
> >> It looks like it could be:
> >>
> >> https://bugs.openjdk.java.net/browse/JDK-8134974
> >>
> >> Can you reproduce the issue at all?
> >>
> >> Roland.=
> >