code review request for initial JDK FDS support (7071907)

[Kelly O'Hair]

On Apr 12, 2012, at 7:44 AM, Daniel D. Daugherty wrote:

>> 
>> Why do we need to change compiler flags besides symbol generation ?
>> 
>> e.g. for gcc -O3 -g3 is perfectly valid combination.
> 
> You'd have to dig into the history of why a FASTDEBUG flavor build
> chose the options that it did. All I'm doing is using their research.

Historically, the hotspot C++ code has sometimes stressed the C++ compilers we have used
over the years, and in addition the dynamic code generated by Hotspot at runtime can sometimes
conflict with the C++ compiler, both use various optimization tactics and sometimes they collide.
I haven't heard of that happening recently, usually it happens when we switch to newer compilers
on Windows and Solaris, but I'm sure it has happened with gcc too.

Adding -g to an optimized build can complicate matters further.
And it's not just the optimization level but all the various compiler options we use.
Sometimes we just have to gear back due to size or time issues compiling one particular file.

So with each 'build flavor' you create unique situations that need to be tweaked because of that unique flavor.

I had tried to make sure that at least with Solaris, when the a compiler bug caused us to add or
adjust the compiler options on a file, that a comment (with CR#) was placed around this area and the makefile
logic would do an 'if compiler version is N.N or less', assuming the bug was fixed in N.N+1.

This is all just a consequence of living in an imperfect world, and walking on the edge of the cliff,
which Hotspot code often does.   Be careful out there.

-kto

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/build-dev/attachments/20120412/73ded1cf/attachment.htm>