Skip to main content

Heads up: java_g and debug versions of java

1 reply [Last post]
Joined: 2004-09-03

There are some changes planned for build 27 with regards to the way we build the debug version of java. Formerly this java was called java_g, and all the shared libraries also contained this "_g" suffix, e.g.,, or jvm_g.dll and java_g.dll. The change will be the complete removal of this _g suffix and the creation of a separate and complete directory with no name changes (no "_g" suffix). Effectively use of ${JDK}/bin/java_g becomes ${JDK}//bin/java.

This will create several benefits:
- Simplifies the makefiles and the build process
- Simplifies the testing scripts
- Allows for mix&match of components
- Allows for any number of builds and subdirectories
- Removes "_g" build time and runtime coding complexities

Besides the name change everyone will need to get used to, Windows users will need to be careful with the mix&match. The _g suffix did help Windows users track the VC++ runtime mixing problems, e.g. dll's dependent on MSVCRTD.DLL can't always mix with dll's built with MSVCRT.DLL. So the debug version of JVM.DLL cannot mix&match with the product version of the J2SE but will have the same name, so Windows users beware.

It's important to note that java_g has never been tested nearly as much as the product version of java, mostly due to the slower performance of java_g. The VM team has historically created what they call the "fastdebug" version of the VM which was a mix&match version for the product version, this is effectively a debug version built with '-g -O'. This fastdebug VM version has been so useful internally and by support people that we will be building the fastdebug version by default in the binary snapshots and not the debug version.

So ${JDK}/bin/java_g will become ${JDK}/fastdebug/bin/java and should run much faster yet provide the same level of assert and debug checking.

Anyone needing a complete and fully debuggable version (${JDK}/debug/bin/java) will need to do a separate and additional build step. The fastdebug version has all the runtime assert and debug checking built into it, but you may be limited as to what the native debuggers can do. All Solaris and Linux builds will mix&match, so any single component could be built 'debug' and used with other fastdebug or product components. The Windows fastdebug version will also not use MSVCRTD.DLL so it will mix&match with the product version (both using MSVCRT.DLL).

Comments are welcome.

Reply viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.
Joined: 2004-09-03

These changes are actually in B28.

So if you are building, let me know if you run into problems.

Would the debug builds being available to download be of interest to anyone? I'm not sure we have the disk space to do this, but I'm curious if anyone would be interested.