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

[Roland Westrelin]

> 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.=
>