Skip to main content

Upcoming Build Change: java_g -> debug/bin/java

No replies
kellyohair
Offline
Joined: 2004-09-03

The java_g executable has a long history but is being phased out so that developers can have more flexibility in mixing and matching product (optimized versions) and debug components of the J2SE. The "_g" naming convention often prevents certain teams from testing their own debug versions inside a product installation tree, or doing any kind of mix&match of product and debug versions of libraries.

One case in particular is the 'fastdebug' build of Hotspot for Linux and Solaris. This is a version of libjvm.so that is built with all the 'assert' checking of the debug version, but compiled with '-g -O' so that it's performance is greatly improved over the vanilla 'debug' version. Hotspot developers use the 'fastdebug' version to gain the 'assert' checking but still get reasonable performance during testing. Since the java_g requires all libraries to be names lib*_g.so, and since shared libraries are somewhat 'self-aware' (their names are baked into them), placing a fastdebug libjvm.so into java_g hasn't been very successful. In general, the source of HotSpot and the J2SE is also sensitive to the library names, forcing the '_g' suffix if it detects that it is itself a '_g' library. These '_g' problems should go away with the upcoming java_g removal.

Currently the formal J2SE build procedure creates the product version and the debug version of the J2SE, soon this will change to separate passes of building the product version and a 'fastdebug' version. Both 'java' versions will be named 'java', just live in different install trees.

This means the name 'java_g' goes away along with all the '_g' library names and is replaced with a separate fastdebug install tree (e.g. jdk1.6.0-debug) that represents a complete jdk installation.

Developers can choose to build the product (optimized) version, or the debug version, or the fastdebug version, or any set they wish.

Let us know what you think.