United StatesChange Country, Oracle Worldwide Web Sites Communities I am a... I want to...
Bug ID: JDK-6454213 RFE: Reduce PIC overhead for Solaris & Unix hotspot VM code
JDK-6454213 : RFE: Reduce PIC overhead for Solaris & Unix hotspot VM code

Details
Type:
Enhancement
Submit Date:
2006-07-28
Status:
Closed
Updated Date:
2012-10-13
Project Name:
JDK
Resolved Date:
2007-03-15
Component:
hotspot
OS:
solaris
Sub-Component:
runtime
CPU:
generic
Priority:
P3
Resolution:
Fixed
Affected Versions:
6
Fixed Versions:
hs10 (b10)

Related Reports
Backport:
Backport:
Relates:
Relates:

Sub Tasks

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

Commit it to dolphin.
                                     
2006-07-28
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.
                                     
2007-02-15
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
                                     
2007-02-16



Hardware and Software, Engineered to Work Together