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 :  
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:

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

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.

EVALUATION Approved for JDK 7 M3 build 58.

EVALUATION Diffs in http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/45463a04ca27

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.

EVALUATION http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/45463a04ca27

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