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

(java_g) RE builds should build fastdebug VM for java_g rather than debug VM, java_g -> debug/java


    • Type: Enhancement
    • Status: Resolved
    • Priority: P2
    • Resolution: Fixed
    • Affects Version/s: 5.0, 6
    • Fix Version/s: 6
    • Component/s: infrastructure
    • Subcomponent:
    • Introduced In Build:
    • Introduced In Version:
    • Resolved In Build:
    • CPU:
      generic, x86, sparc
    • OS:
      generic, linux, solaris_9, windows_2000


      Control RE builds should build fastdebug VM for java_g rather than debug VM

        debug VM build == compilation with -g and no optimization
        fastdebug VM build == compilation with -g and -O

        The fastdebug VM runs significantly faster but takes a little longer
          to build (roughly 15-30min per libjvm_g.so built).
        Most or much of the VM testing is done with the fastdebug VM.
        The PRT builds always build a fastdebug VM.

        This should only impact java_g RE bundles.
        This is only for Solaris and Linux.
        All assert checking remains the same between fastdebug and debug VM's.

      Big Positives:
        It improves the value of java_g to licensees and support, and everyone.
          (The current RE java_g is horribly slow).
        Prevents later risks associated with support having to do their own builds of the
          fastdebug VM after formal RE builds and/or beta/fcs deliveries.
        Allows java_g from RE to be tested without modification.
        Increases testing exposure for fastdebug VM builds, making it more valuable to support.

        It could increase total RE build time by 30-60 minutes on sparc.
        Direct debugging the RE libjvm_g.so could be slightly impaired, however nobody
          was found that actually did this. This doesn't appear to be the intent of java_g
          from RE anyway. The necessary files needed to do this aren't easily available.
          Most VM engineers build and debug their own libjvm_g.so.

        It appears fastdebug VM's by default are built as a libjvm.so and are meant to
          be dropped into a 'java' installation as a replacement for the product libjvm.so.
          Simply copying or using a softlink of libjvm_g.so -> libjvm.so for fastdebug
          will not work 100%, however, the hotspot makefiles have a make macro G_SUFFIX which
          can be used to deal with this, building the fastdebug version directly as a
          libjvm_g.so, and this appears to solve all the problems.
          NOTE: Several issues here, shared libraries have their name baked into them
                (SONAME), and a libjvm_g.so should only load it's fellow lib*_g.so
                relatives, not the non _g ones. I never liked this _g naming convention,
                seems like a major hassle, seemed better to just have a lib/debug
                directory that you could LD_LIBRARY_PATH to ... oh well ...

      See the suggested fix.

      ###@###.### 2004-07-01

      This change request has turned into a complete removal of the java_g '_g' suffix convention AND the use of a fastdebug VM.

      ###@###.### 2005-2-20 20:46:59 GMT


          Issue Links



              • Assignee:
                ohair Kelly Ohair (Inactive)
                ohair Kelly Ohair (Inactive)
              • Votes:
                0 Vote for this issue
                1 Start watching this issue


                • Created: