JDK-8166087 : Desire x86 ud2 instruction to indicate end of code block
  • Type: Enhancement
  • Component: hotspot
  • Sub-Component: compiler
  • Affected Version: 9
  • Priority: P3
  • Status: Closed
  • Resolution: Not an Issue
  • Submitted: 2016-09-14
  • Updated: 2017-05-18
  • Resolved: 2017-05-18
The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.
JDK 10
10Resolved
Related Reports
Relates :  
JDK-8153270 - SIGSEGV in stack walking with Sun Studio Performance Analyzer
Description
The Oracle Studio Performance Analyzer walks x86 instructions while a target
application is running as part of call-stack unwind in order to attribute
performance metrics to user source code.  Starting with Java 9, there have
been problematic instruction byte sequences that have caused SEGVs.  They
look like:
    jmp *(%reg)
    nop
where the nop can take many different forms and apparently serves to pad out
until the next multiple-of-8 boundary.  It is desirable that the end of a
code block, when there will be no more executable instructions, would be
indicated with an x86 ud2 (0x0f 0x0b) before the nop so that there is a clear
indicator that no further bytes should be walked.  Please let me know if
there is anything about this request that needs further explanation.
Comments
There is not enough available to prove that this issue is related to JIT-compilation. I'm closing the issue as "Incomplete" until evidence becomes available.
08-02-2017
Hi, a closer look at this issue does not reveal any facts to indicate that the problematic instruction sequences are generated by any of HotSpot's JIT compilers. Please see more details below. I launched a JDK 9 b138 VM with the -version option on a linux x86_64 machine. I used two configurations: C1 compilation only (-XX:TieredStopAtLevel=1) and C2 compilation only (-XX:-TieredCompilation). To trigger as many compilation as possible, I ran the JVM with the -Xcomp option. In both configurations, I had the VM print the generated assembly code (using -XX:+PrintAssembly) I checked the generated assembly output and was not able to find (in either of the two configurations) a single instance of the code sequence mentioned in the current enhancement. It could be, however, that the problematic instruction is generated in a more special setting (i.e., with more profile information available or with some method whose compilation my experiment did not trigger). Can the person who filed this enhancement please provide us a setup (i.e., VM version, test case or application) in which any of the JIT compilers generates the problematic instruction sequence? That would prove that this is indeed a JIT-related issue and would also help the JIT team isolate the cause of the problem. Thank you! Best regards, Zoltan
03-11-2016
Could this issue possibly be related to JDK-8153270?
02-11-2016