JDK-6367074 : Hotspot should isolate JVM details for library linking
  • Type: Enhancement
  • Component: hotspot
  • Sub-Component: runtime
  • Affected Version: 6
  • Priority: P3
  • Status: Closed
  • Resolution: Future Project
  • OS: generic
  • CPU: generic
  • Submitted: 2005-12-23
  • Updated: 2012-09-17
  • Resolved: 2010-06-22
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 8
8-poolResolved
Related Reports
Relates :  
JDK-6272349 - Use C1 as fast compiler in a tiered system with C2
Relates :  
JDK-6367077 - Purge LD_LIBRARY_PATH usage from the launcher
Description
This RFE is expected to improve the dynamic (and static) linking story for Java SE by providing a linkage target that hides Hotspot implementation details, specifically to do with the current situation with per-compiler libjvm.so files but covering more issues than that. See 4777947 for history and additional details. Here is the specific proposal from Fred Oliver in the notes of that CR:

"There is quite a long email trail associated with this bug, and since I
am passing it on, I document some of the goals and constraints, and a
possible solution.

Requirement

(1) Native applications embedding Java using the invocation API should
not be required to set the LD_LIBRARY_PATH in advance (for dynamicly
loading the JVM).  Applications which staticly link to the JVM should
require LD_LIBRARY_PATH set only to select the JVM to use.

Goals

(2) The same solution should work on both Solaris and Linux.
(3) The solution should allow the linker argument "-z defs" so that no
symbols are left undefined, only to be detected later on.

Proposal

Create a new libjvmsyms.so which
(a) Lives in jre/lib/<processor> with the other native libraries.
(b) Defines every private JVM entry point required by our native
    libraries. 
    + All of our native libraries requiring these entry points will be
      linked against this new library (instead of libjvm.so), and bound
      to it by including $ORIGIN in the runpath.
    + None of these entry points will ever actually be called, because
      the JVM will be loaded first, and its symbols will override those
      in the new library.
(c) Implements the entry points as fatal errors (to guarantee that they
    aren't called)."
Comments
EVALUATION The stumbling block to this issue is really that we have two compilers implemented as a monolithic libjvm.so. The tiered-compilation will solve this problem, whereby we will have a single libjvm.so which contains both C1 and C2 and adaptively uses the compilers. Though the tiered compilation work is almost done, we have to wait for the libraries to be consolidated. See 6272349. with that in mind, its not very clear what else this CR is supposed to address which are not being addressed by all the other LD_LIBRARY_PATH sanification work.
10-11-2006