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

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

Observations:
  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.

Scope:
  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.

Negatives:
  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.


Issues:
  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