JDK-6834177 : Running jsynprog on Solaris Nevada can cause JVM crash
  • Type: Bug
  • Component: hotspot
  • Sub-Component: compiler
  • Affected Version: 6u14
  • Priority: P3
  • Status: Closed
  • Resolution: Fixed
  • OS: solaris_nevada
  • CPU: sparc
  • Submitted: 2009-04-25
  • Updated: 2011-03-08
  • Resolved: 2011-03-08
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 6 JDK 7 Other
6u18Fixed 7Fixed hs16Fixed
Related Reports
Relates :  
JDK-5082720 - Remove adapter frames
Description
Running jsynprog on Solaris Nevada can cause JVM crash.

We use this program in Sun Studio Performance Analyzer testing.
Our tests show this problem on Solaris Nevada SPARC systems (snv_110, snv_111) 
with these java versions:
jdk1.6.0_14-b02 
jdk1.7.0-b48 

We have three Solaris Nevada SPARC systems (2 - snv_110,
1 - snv_111), and the problem happens on all of them, at different
probabilities:

uname -a: SunOS bohr 5.11 snv_110 sun4u sparc sun4u
Sysinfo: SunOS-64-bit, 2 CPUs, sparc 5.11 UltraSPARC I&II
Start date: Wed Apr 22 22:01:22 PDT 2009

I don't see this problem on x64 Solaris 11 systems. Also, it looks
like the problem happens in 64-bit mode only (when 64-bit java is used).

See "Comments" section for details.
Comments
EVALUATION Approved for JDK 7 M3 build 58.
04-05-2009
EVALUATION Diffs in http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/45463a04ca27
30-04-2009
PUBLIC COMMENTS Problem: The code which generates a native call wrapper and a dtrace nmethod uses VM's static buffer AdapterHandlerLibrary::_buffer for the code generation before moving it into CodeCache. During the code generation in the static buffer a runtime call distance is < 32 bits and the short form of a call instruction is generated. It may cause problem for 64-bit VM when the relative call distance to runtime from these methods may not fit into 32-bit if address distance between CodeCache and VM's code > 32 bits. Solution: Use CodeCache buffer blob instead of static buffer AdapterHandlerLibrary::_buffer. Also throw an exception in dtrace runtime if nmethod was not generated.
30-04-2009
EVALUATION http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/45463a04ca27
30-04-2009
EVALUATION The distance for call instruction (call to dtrace_method_entry) in compiled native wraper > 32 bits since libjvm.so is loaded far from code cache where native wraper is placed: 0xfffffffb84500000 jdk/6_14/ea/b02/binaries/solaris-sparcv9/fastdebug/jre/lib/sparcv9/server/libjvm.so Call arguments: [7] Assembler::wdisp(0xfffffffbec8085bc, 0x0, 0x1e, 0x108, 0x528, 0x54), at 0xfffffffb6541e74c [8] NativeInstruction::set_wdisp(0x7fda9b4f, 0xfffffffbec8085bc, 0x1e, 0xffffffff7dafe218, 0xffffffff7dafeb78, 0x20), at 0xfffffffb65bcf0a8 [9] NativeCall::set_destination(0xffffffff79512d24, 0xfffffffb65d1b2e0, 0xffffffffffffffff, 0x5, 0x0, 0xffffffff7951301d), at 0xfffffffb65bcebf8 [10] Relocation::pd_set_call_destination(0xffffffff7dafdb58, 0xfffffffb65d1b2e0, 0xffffffff7dafeb78, 0xffffffff7dafdc80, 0x100139268, 0x100139268), at 0xfffffffb65cf6e58 void set_destination(address dest) { set_long_at(0, set_wdisp(long_at(0), dest - instruction_address(), call_displacement_width)); } instruction_address() = 0xffffffff79512d24 dest = 0xfffffffb65d1b2e0 long_at(0) = 0x7fda9b4f dest - instruction_address() = 0xfffffffbec8085bc ( -0x4137f7a44 ) does not fit into 32 bits. call_displacement_width = 0x1e (30) [t@2 l@2]: x 0xfffffffb65d1b2e0 0xfffffffb65d1b2e0: dtrace_method_entry : 0x9de3bed0 The NativeFarCall should be used instead of NativeCall. This is the code in SharedRuntime::generate_native_wrapper() which generates the call: __ call_VM_leaf(L7_thread_cache, CAST_FROM_FN_PTR(address, SharedRuntime::dtrace_method_entry), G2_thread, O1); The code in MacroAssembler::call() generates call() instead of jumpl_to() because the wrapper is generated, first, in AdapterHandlerLibrary::_buffer which is at the same address space as libjvm.so: [t@1 l@1]: x 0xfffffffb634745a4 0xfffffffb634745a4: __1cVAdapterHandlerLibraryH_buffer_+0x00fc: 0xca70a218 __1cVAdapterHandlerLibraryH_buffer_ == AdapterHandlerLibrary::_buffer
25-04-2009