Uploaded image for project: 'JDK'
  1. JDK
  2. JDK-6367074

Hotspot should isolate JVM details for library linking

    XMLWordPrintable

    Details

    • Type: Enhancement
    • Status: Closed
    • Priority: P3
    • Resolution: Future Project
    • Affects Version/s: 6
    • Fix Version/s: 8-pool
    • Component/s: hotspot
    • Labels:
      None
    • Subcomponent:
    • CPU:
      generic
    • OS:
      generic

      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)."

        Attachments

          Issue Links

            Activity

              People

              Assignee:
              Unassigned Unassigned
              Reporter:
              psoper Pete Soper (Inactive)
              Votes:
              0 Vote for this issue
              Watchers:
              3 Start watching this issue

                Dates

                Created:
                Updated:
                Resolved:
                Imported:
                Indexed: