Performance: Hotspot Solaris OPT level increase for X86/sparcv9 and workaround removals

The current mustang hotspot makefiles contain a default of -xO3 on x86 and sparcv9 and could benefit from using -xO4 with the new SS11 compilers. Past experience with SS10 has shown that it didn't, but it would be worth a try.

And additional thought about this is that the -xO4 and -xO2 settings are used pretty extensively, but the -xO3 is not, the compiler team themselves use -xO4 in their bootstrap process and concentrate a great deal on this opt level. So use of -xO4 may have some stability advantages. So if -xO4 and -xO3 are about the same, it may be wise to stay with -xO4, just a thought.

Also, there are various workarounds in the makefiles that turn optimization down, sometimes to get a frameptr on X86 (which can be done with -xregs=no%frameptr instead of turning optimizations off), or to avoid past bugs in the compiler or current bugs in SS11. These makefile lines should be well documented but many could be removed. When I did the alacrity runs for Solaris AMD64 I removed all the workarounds and built everything with -xO4, the alacrity runs didn't show any difference either way, but if we don't need the workarounds it would be good if they were removed.

See the suggested fix.
There are some areas in Solaris sparc/x86 makefiles that may lower optimization levels or specify other workarounds for limitations of the cc55 compiler. Once we upgrade to the cc57 (SS10) compiler these assumptions may no longer be valid and we may want to remove the workarounds, potentially improving performance.

Two locations that I know about are:
1. sparcWorks.make:114 sets x86 opt level to -xO3 to workaround a cc55 bug; we might be able to up this to -xO4 for cc57.

2. "optimized" build should be built & tested to ensure that the cc57 workarounds of 6234407/6233962 mentioned in fastdebug.make are not needed in optimized.make. Thanks to ###@###.### for pointing this out.

There are surely other areas that need cleanup after the SS10 switch - needs investigation.


###@###.### 2005-03-02 16:06:51 GMT

Also there are some new compilation warnings with SS10 in fastdebug:
"/nightly/ws/src/share/vm/oops/generateOopMap.hpp", line 118: Warning: The variable s has not yet been assigned a value.
"/nightly/ws/src/share/vm/oops/generateOopMap.hpp", line 118: Warning: The variable s has not yet been assigned a value.

"/nightly/ws/src/share/vm/code/vtableStubs.cpp", line 122: Warning: Initializing const VtableStub& to a NULL value.

Or should this be a different bug?
###@###.### 2005-03-21 19:19:49 GMT
*** (#1 of 2): 2005-03-02 11:06:51 EST ###@###.###
*** Last Edit: 2005-03-21 14:19:49 EST ###@###.###

As a result of the fix for 6295979 the cc57 workarounds of 6234407/6233962 mentioned in fastdebug.make will be gone as of b48. The C++ compiler bugs have been fixed so there should be no longer be any need to check this particular issue with respect to the optimized build.
*** (#2 of 2): 2005-08-11 09:06:13 EDT ###@###.###