ADDITIONAL SYSTEM INFORMATION :
Primarily observed on:
macOS High Sierra 10.13.6 (17G4015)
MacBook Pro (Retina, 13-inch, Early 2015)
Intel(R) Core(TM) i7-5557U CPU @ 3.10GHz
8GB RAM

java version "1.8.0_201"
Java(TM) SE Runtime Environment (build 1.8.0_201-b09)
Java HotSpot(TM) 64-Bit Server VM (build 25.201-b09, mixed mode)

java version "9.0.1"
Java(TM) SE Runtime Environment (build 9.0.1+11)
Java HotSpot(TM) 64-Bit Server VM (build 9.0.1+11, mixed mode)

openjdk 11.0.2 2019-01-15
OpenJDK Runtime Environment 18.9 (build 11.0.2+9)
OpenJDK 64-Bit Server VM 18.9 (build 11.0.2+9, mixed mode)

openjdk version "12-ea" 2019-03-19
OpenJDK Runtime Environment (build 12-ea+29)
OpenJDK 64-Bit Server VM (build 12-ea+29, mixed mode, sharing)


A DESCRIPTION OF THE PROBLEM :
A Java process occasionally terminates with Illegal Instruction (SIGILL), exit code 132 when running obfuscated code. We originally observed this issue on Windows 7 with Java 8, but most of our testing of the issue has been on macOS with Java 8. The issue appears in Java 8-12 (have not tested 13). It has not been observed in Java 7. Even examining the .crash file the core file from macOS, it is not clear exactly why the termination happens (It happens on thread zero, but that appears to be as part of an error handler).

Testing suggests that available computational resources may have an effect on this: this happens on Mac Book Pro with 2 cores, but not a Mac Book Pro with 4 cores (but does happen on a 2-core VM on the 4-core mac). Some experimentation with Java 8 suggested that the issue happened when compilation was queued but not when the compilation happened immediately.

Running Java with -Xint the issue does not happen. JIT compilation of a particular method, RandomizedIdentifierGenerator.b(), appears to affect the behavior. This method calls, in addition to other methods, n.e() and n.h(). Excluding b() from JIT compilation prevents the error from happening. Alternatively, preventing both e() and h() from being inlined into b() also prevents the issue from happening.

Reviewing the assembly produced when a run terminates unexpectedly, sometimes bad instruction emitted (this is the level of detail of the assembly provided by hsdis-amd64.dylib):

  0x000000011ad807bd: data16 xchg %ax,%ax
  0x000000011ad807c0: jmpq 0x000000011ad80f90 ; {no_reloc}
  0x000000011ad807c5: add %al,(%rax)
  0x000000011ad807c7: add %al,(%rax)
  0x000000011ad807c9: add %ch,%cl
  0x000000011ad807cb: lret
  0x000000011ad807cc: (bad)
  0x000000011ad807cd: add %al,(%rax) ;*new {reexecute=0 rethrow=0 return_oop=0}
                                                ; - java.lang.StringLatin1::charAt@10 (line 47)
                                                ; - java.lang.String::charAt@12 (line 693)
                                                ; - java.lang.Integer::parseInt@184 (line 650)

In testing the larger, original program, the issue would happen roughly 1% - 10% of the time. Unfortunately the frequency with the smaller reproduction is less, roughly 0.03% - 0.5%.


STEPS TO FOLLOW TO REPRODUCE THE PROBLEM :
The following is a link to a zip file that contains:
    reproduction.jar - obfuscated jar that reproduces the issue
    reproduction.sh - script to run project, record the results, and reports progress to the terminal
    short.pattern - file read by the project

    run-with-assembly.log - log of the failure with disassembly being recorded
    java_2019-01-29-160606_Mikes-MacBook-Pro-3.crash - macOS crash file

http://files.preemptive.com.s3.amazonaws.com/Support/jit_bug/reprod.zip?AWSAccessKeyId=AKIAJMVMID2GL2JYZZ6Q&Expires=1580940869&Signature=moVY4HPbV%2fgSph2fzseVbHHN7RI%3d

The issue can be observed by running 10k iterations of the reproduction project, which takes about 40 minutes:

    ./reproduction.sh

The test script provided defaults to running 10k iterations. The reproduction project generates a random sequence of identifiers (that is discarded), occasionally resetting internal structures. The included short.pattern file is a record of the number of identifiers generated before each reset. This file is read by the reproduction project, effectively replaying the function call sequences that lead to the issue in testing.

run-with-assembly.log is a record of the disassembly of compiled methods including instructions hsdis-amd64.dylib listed as "(bad)". java_2019-01-29-160606_Mikes-MacBook-Pro-3.crash, the macOS crash file, is included for this same run.


EXPECTED VERSUS ACTUAL BEHAVIOR :
EXPECTED -
Java would run and then terminate with a zero return code every time.
ACTUAL -
Java terminates with exit code 132 on rare occasion.

---------- BEGIN SOURCE ----------
I do not know of a reproduction directly from source code.
---------- END SOURCE ----------

CUSTOMER SUBMITTED WORKAROUND :
This issue can be worked around by instructing the JIT compiler to exclude b() from compilation.

FREQUENCY : rarely