Some Eclipse Foundation services are deprecated, or will be soon. Please ensure you've read this important communication.

Bug 493669

Summary: Eclipse Mars crashes on Mac OS 10.11.4 while compiling with Oracle jdk1.8.0_92 JDK
Product: [Eclipse Project] JDT Reporter: Xabriel J Collazo Mojica <xabrielc>
Component: CoreAssignee: Stephan Herrmann <stephan.herrmann>
Status: VERIFIED NOT_ECLIPSE QA Contact:
Severity: blocker    
Priority: P3 CC: ed, frank.van.werven, jarthana, register.eclipse, stephan.herrmann
Version: 4.5.2   
Target Milestone: 4.6 RC2   
Hardware: Macintosh   
OS: Mac OS X   
Whiteboard:
Attachments:
Description Flags
hs_err_pid file
none
replay_pid file
none
Mac crash report none

Description Xabriel J Collazo Mojica CLA 2016-05-13 12:59:51 EDT
Created attachment 261732 [details]
hs_err_pid file

Eclipse Mars crashes while compiling with Oracle jdk1.8.0_92 JDK.

It consistently crashes, rendering Eclipse unusable.

If I use Oracle jdk1.8.0_91, the crash goes away.

I am attaching:

hs_err_pid file
replay_pid file
Mac crash report
Comment 1 Xabriel J Collazo Mojica CLA 2016-05-13 13:00:30 EDT
Created attachment 261733 [details]
replay_pid file
Comment 2 Xabriel J Collazo Mojica CLA 2016-05-13 13:00:51 EDT
Created attachment 261734 [details]
Mac crash report
Comment 3 Stephan Herrmann CLA 2016-05-13 13:40:45 EDT
Looks like the JIT cannot compile one of our classes:

Current CompileTask:
C2: 349035 16887       4       org.eclipse.jdt.internal.compiler.parser.TypeConverter::decodeType (1094 bytes)

---------------  P R O C E S S  ---------------

Java Threads: ( => current thread )
...
=>0x0000000101804800 JavaThread "C2 CompilerThread2" daemon [_thread_in_native, id=29955, stack(0x00007000010cd000,0x00007000011cd000)]



If s.o. identifies the Oracle bug and reports the code scheme that triggers it, we could try to avoid that scheme, but this sure is not an Eclipse bug.

As a workaround I suggest you play with the -XX:CompileCommand VM option, see http://docs.oracle.com/javase/8/docs/technotes/tools/unix/java.html
Comment 4 Till Brychcy CLA 2016-05-13 15:04:37 EDT
Seems to be this one:
https://bugs.openjdk.java.net/browse/JDK-8154831
Comment 5 Stephan Herrmann CLA 2016-05-14 06:17:59 EDT
(In reply to Till Brychcy from comment #4)
> Seems to be this one:
> https://bugs.openjdk.java.net/browse/JDK-8154831

Thanks, according to that bug, this should be fixed in Oracle Java 9 ea.
@Xabriel, is upgrading to early access builds of Java 9 an option for you?

Next best solution should be (as per previous comment)
  -XX:CompileCommand=exclude,org.eclipse.jdt.internal.compiler.parser.TypeConverter::decodeType


OTOH, the JDK bug doesn't (yet) have any hints on how to rearrange our source code to avoid triggering this bug. => Nothing we can do on JDT side.
Comment 6 Jay Arthanareeswaran CLA 2016-05-16 07:27:39 EDT
Verified for 4.6 RC2.
Comment 7 Xabriel J Collazo Mojica CLA 2016-05-16 14:15:19 EDT
@Stephan Java 9 is not an option for me, but good to know the 'XX:CompileCommand' is a workaround. I understand that JDT can't workaround it. Will track the JVM defect.
Comment 8 Stephan Herrmann CLA 2016-07-21 11:14:00 EDT
*** Bug 498283 has been marked as a duplicate of this bug. ***
Comment 9 Ed Willink CLA 2016-07-26 01:57:41 EDT
(In reply to Stephan Herrmann from comment #5)
> OTOH, the JDK bug doesn't (yet) have any hints on how to rearrange our
> source code to avoid triggering this bug. => Nothing we can do on JDT side.

It gives a very strong clue 

"CastII node prematurely goes away and causes a cascade of other eliminations which severely corrupts the graph (the actual crash happens due to a memory edge coming from a non-dominating region). "

Looking at TypeConverter::decodeType I see "int start" and numerous "((long) start << 32) + end)" subexpressions. Clearly an unusual and repetitive cast subject to a bad optimization.

Suggest an explicit

long longStart = start;
long offset = (longStart << 32) + end.

perhaps an a per-case basis to avoid slowing down the other cases.
Comment 10 Stephan Herrmann CLA 2016-07-26 16:22:35 EDT
(In reply to Ed Willink from comment #9)
> (In reply to Stephan Herrmann from comment #5)
> > OTOH, the JDK bug doesn't (yet) have any hints on how to rearrange our
> > source code to avoid triggering this bug. => Nothing we can do on JDT side.
> 
> It gives a very strong clue 

Thanks for the update, this wasn't present last time I looked :)

I filed bug 498527 for the proposed follow-up.

Since I've never seen the crash, fixing this would require the help of s.o. who can reproduce the problem and will try our workarounds.
Any volunteers?