[prev in list] [next in list] [prev in thread] [next in thread] 

List:       openjdk-hotspot-compiler-dev
Subject:    Re: Tips for diagnosing C2 compile crashes?
From:       Volker Simonis <volker.simonis () gmail ! com>
Date:       2013-07-26 9:10:47
Message-ID: CA+3eh12ZF_XOq=iie_mHMxGAES2TTB_eijVEeeZuN9hh0cNYFQ () mail ! gmail ! com
[Download RAW message or body]

On Thu, Jul 25, 2013 at 4:33 PM, Jørgen Austvik
<Jorgen.Austvik@kantega.no> wrote:
> Hi,
> 
> we have a problem where C2 SIGSEGVs in PhaseIdealLoop::build_loop_late_post(Node*) \
> seen in 1.7.0_17-b02 and 1.7.0_25-b15 on linux-amd64. When I google sigsegv \
> build_loop_late_post, I see that I am not alone (play framework community seems to \
> be hit with some fascinating cargo cult workarounds). 
> V  [libjvm.so+0x6835b4]  PhaseIdealLoop::build_loop_late_post(Node*)+0x154
> V  [libjvm.so+0x683b1c]  PhaseIdealLoop::build_loop_late(VectorSet&, Node_List&, \
> Node_Stack&)+0x13c V  [libjvm.so+0x68ab07]  \
> PhaseIdealLoop::build_and_optimize(bool, bool)+0x7d7 V  [libjvm.so+0x3b805a]  \
> Compile::Optimize()+0xbea V  [libjvm.so+0x3b8f5c]  Compile::Compile(ciEnv*, \
> C2Compiler*, ciMethod*, int, bool, bool)+0xdac V  [libjvm.so+0x32ae52]  \
> C2Compiler::compile_method(ciEnv*, ciMethod*, int)+0x142 
> It always crashes (on different linux distributions/machines/JVM versions) on the \
> same method (from jetty-util-8.1.8.v20121106.jar): 
> Current CompileTask:
> C2:687410906   66 %           org.eclipse.jetty.util.URIUtil::canonicalPath @ 26 \
> (633 bytes) 

The "%" indicates that it is an "OnStackReplacment" compilation

> Since this was a public static method I naively thought I could reproduce the crash \
> with a simple for-loop, the same JVM on the same host with the same library version \
> - and with -XX:+PrintCompilation I could see that the method was compiled, but it \
> didn't crash. 
> OK, so maybe the method had to be in its "natural environment" I thought, and \
> started up the server process that uses Jetty, and ran our standard performance \
> test on it. It crashed beautifully with hs_err and core the first time I ran it, so \
> I wanted to see if it could be reproduces. I started again, saw that \
> canonicalPath() was compiled, but it doesn't crash. I have tried to run the load \
> against the server while restarting it every 2 minutes to trigger compilations, and \
> it doesn't crash, so I think the crashes must be depending on how the compilation \
> happens (the statistical information collected could trigger different \
> compilations?). 

Is it compiled as OSR again (i.e. does PrintCompilation still report
"%") when it does not crash?

> Q: Is there any way to trigger different compilations of that method so that I can \
> try to figure out which compilation setting/methods that causes the SIGSEGV? 

You could try to play around with the following options:

  product_pd(intx, CompileThreshold,                                        \
          "number of interpreted method invocations before (re-)compiling") \
                                                                            \
  product_pd(intx, BackEdgeThreshold,                                       \
          "Interpreter Back edge threshold at which an OSR compilation
is invoked")\

For x86 they have the following default values:

define_pd_global(intx, CompileThreshold,             10000);
define_pd_global(intx, BackEdgeThreshold,            100000);

Another problem may be that the inlining is different. In the case
where it does not crash you can see what has been inlined with the
dignostic option "-XX:+PrintInlining" option. Unfortunately you won't
see what's different for the crashing case because it will crash
before it can print that information:)

> Best Regards
> Jørgen Austvik
> 
> --
> Kantega AS
> Erling Skakkes gt. 25, 7013 Trondheim
> E-post: jorgen.austvik@kantega.no
> Mobil: +47 90 19 78 86
> Sentralbord: +47 73 80 68 00
> Fax: +47 73 80 68 01
> www.kantega.no
> 
> 
> 
> 


[prev in list] [next in list] [prev in thread] [next in thread]