JDK-6970542 : (process) Runtime.exec() call on Solaris/SPARC is 3-4 slower than on Java 5.
  • Type: Bug
  • Component: core-libs
  • Sub-Component: java.lang
  • Affected Version: 6u21
  • Priority: P3
  • Status: Closed
  • Resolution: Duplicate
  • OS: solaris
  • CPU: sparc
  • Submitted: 2010-07-20
  • Updated: 2011-02-16
  • Resolved: 2011-01-11
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.
6-poolResolved 7-poolResolved
Related Reports
Duplicate :  
Relates :  
Runtime.exec() call on Solaris/SPARC is slow on Java 6 compared to Java 5.
Do this in a loop

           long begin = System.nanoTime();
           final Process process = runtime.exec(cmdStr);
           long diff = System.nanoTime() - begin;

and compare diff on both Java 5 and Java 6 JREs.
Wrt. the Runtime.exec() call, Java 6 is approx. 3-4 times slower on a SPARC system compared to Java 5 on a SPARC system. On x86-systems the Runtime.exec call from Java 6 is faster than on Java 5.

Testprogram and Testresults are attached to this report.

EVALUATION After a call to fifo_stropen the thread waits for the stream to be created and sits spining on mod_lock in a route called defalt_lock_backoff (really just mutex_enter) which is called from mod_hold_stub which is checking that the modules for the stream (pipe) are loaded and open. Other thread content on the same mod_lock is a DTRACE helper thread which gets kicked off on a fork. 1.5 don't have this.