Issue | Fix Version | Assignee | Priority | Status | Resolution | Resolved In Build |
---|---|---|---|---|---|---|
JDK-2176858 | 7 | Xiaobin Lu | P3 | Closed | Fixed | b10 |
JDK-2171809 | 6u4 | Xiaobin Lu | P3 | Closed | Fixed | b03 |
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.
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.
- backported by
-
JDK-2171809 RFE: Reduce PIC overhead for Solaris & Unix hotspot VM code
- Closed
-
JDK-2176858 RFE: Reduce PIC overhead for Solaris & Unix hotspot VM code
- Closed
- relates to
-
JDK-6647068 libjvm.so is not built PIC
- Closed
-
JDK-6717128 Using relative path for ALT_OUTPUTDIR does not work properly
- Closed