Not sure where to post this...

[Kelly O'Hair]

Just some background...  sorry if this is a repeat...

The concept of "fastdebug" (essentially building with both -O and -g, and
also including any native code assert checking) started with the Hotspot
team on Solaris and Linux at least partially because of the big performance
differences seen between pure -g+asserts and -O built native binaries.
On Windows, there seemed to be less justification for this, so most
developers that used Windows and wanted to debug may have just used
the product bits (-O) or a plain debug build. The number of Hotspot
developers using Windows is probably not as high now I suspect.

In JDK5, the Release Engineering teams would build the product bits and
the debug bits (java_g), but java_g was so slow no serious testing happened.
The Hotspot team would build a fastdebug VM, put it into a product JDK
and test that.

In JDK6, the fastdebug builds displaced the formal debug builds, giving us
a fastdebug "java" build with no "_g" naming issues, and something that could
potentially be tested someday. Removing the "_g" also allowed for pieces
of a fastdebug or debug install to be used in a product install image,
following the Hotspot team's lead.

Windows fastdebug builds may indeed be exactly the same as debug builds
in terms of the compilation flags. We did remove all use of msvcrtD.dll
in favor of consistent msvcrt.dll usage (msvcrtD.dll locks you in and
cannot be redistributed).

When we removed the "_g" in JDK6, there was some good simplication
that happened around the "LoadLibrary" logic all over the JDK and in the
Hotspot code as I recall. All the funny logic about having to create the
right "*_g.dll" or "lib*_g.so" names should have gone away.
A fastdebug JDK install tree should look the same as a product install
tree, so if it's a product, debug or fastdebug install image, the logic
around doing a "LoadLibrary" or dlopen() should not be different.

Sorry for the long history...  But I'm suspecting that we missed a place
somewhere....

-kto

Ted Neward wrote:
> … so I’ll post it here.
> 
>  
> 
> After making the makefile change Kelly described, I cannot get the 
> fastdebug builds to run. Specifically, if I trace execution with windbg, 
> I find that hpi::initialize() (called from os::init_2() in 
> hotspot\src\os\windows\vm\os_windows.cpp) fails for some reason—haven’t 
> traced it deeper than that yet. Given that my previous build failures 
> were with files from that same subsystem (HPI), I thought I might see if 
> anybody here thinks the two are related.
> 
>  
> 
> If this needs to be cross-posted to hostpot, please feel free to suggest 
> which list it should go to—I’m not sure. :-/
> 
>  
> 
> Ted Neward
> 
> Java, .NET, XML Services
> 
> Consulting, Teaching, Speaking, Writing
> 
> http://www.tedneward.com
> 
>  
> 
> 
> No virus found in this outgoing message.
> Checked by AVG Free Edition.
> Version: 7.5.516 / Virus Database: 269.21.2/1305 - Release Date: 
> 2/29/2008 6:32 PM
>