JDK-6454213 : RFE: Reduce PIC overhead for Solaris & Unix hotspot VM code
  • Type: Enhancement
  • Component: hotspot
  • Sub-Component: runtime
  • Affected Version: 6
  • Priority: P3
  • Status: Closed
  • Resolution: Fixed
  • OS: solaris
  • CPU: generic
  • Submitted: 2006-07-28
  • Updated: 2012-10-13
  • Resolved: 2007-03-15
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
6u4Fixed 7Fixed hs10Fixed
Related Reports
Relates :  
JDK-6717128 - Using relative path for ALT_OUTPUTDIR does not work properly
Relates :  
JDK-6647068 - libjvm.so is not built PIC
Description
Currently, JVM is built as a position-independent shared object (libjvm.so). Java launcher and other JDK tools in bin directory use dlopen() and invocation API to dynamically load libjvm.so. This mechanism is used by native applications as well to invoke java code. 

However there is an overhead associated with position-independent code, because every access to global variables needs to go through Global Offset Table (GOT) first (GOT-indirect). On x86, a register (%ebx) must be set aside to access GOT. PIC code is less efficient than non-PIC code due to the extra level of indirection. Plus, compiler may generate better code for non-PIC (it has an extra register (%ebx) to use on x86, the code is shorter which means compiler can inline more aggressively). A recent study showed PIC has a significant overhead in JNI calls and startup time.

Both Solaris and Linux allow non-PIC shared libraries. However, it is not recommended, because when a non-PIC shared library is loaded at runtime, the linker has to patch text segment to relocate symbols. It means the library image can not be shared among multiple processes because each process now has its own private copy. A common objection to using non-PIC libraries is that having non-PIC shared libraries may speed up invidual application but at the cost of overall system performance. In fact, latest Solaris 10 compiler and Linux gcc for AMD64 do not allow building non-PIC shared library at all. 

This RFE is filed for reducing the PIC overhead while keeping the share benefit as the PIC code.
Comments
EVALUATION Webrev: http://prt-web.sfbay.sun.com/net/prt-archiver.sfbay/data/archived_workspaces/main/rt_baseline/2007/20070215142118.xl116366.hotspot/workspace/webrevs/webrev-2007.02.15/index.html
16-02-2007
EVALUATION The final approach we are taking for this RFE is we only compile the GC related code, namely, all the code under src/share/vm/memory, oops, gc_interface and gc_implementation directories, as non-PIC code. This can achieve the main advantage we get out of fat launcher project and on the other hand, we could still have reasonable sharability for the VM library. I have a detailed write up at the project wiki page: http://j2se.sfbay.sun.com/web/bin/view/Main/FatJava. Here is summary of the performance data. On Solaris x86, with the change, we saw up to 10% reduction of GC pause time with serial collector and 6.23% with CMS collector and 3.5% reduction with parallel collector. There are almost no regressions in terms of performance except we loose some sharability (about 5%) and we saw 10% startup time increase on applications such as Noop. This is mostly due to the additional relocations caused by the non-PIC code. I consider these as decent trade-offs.
15-02-2007
EVALUATION Commit it to dolphin.
28-07-2006