code review request for initial JDK FDS support (7071907)

[Dmitry Samersoff]

Dan,

We link two semantically different options together and it make me 
uncomfortable with this fix.

Why do we need to change compiler flags besides symbol generation ?

e.g. for gcc -O3 -g3 is perfectly valid combination.

-Dmitry


On 2012-04-12 17:50, Daniel D. Daugherty wrote:
> On 4/11/12 7:24 PM, Mikael Vidstedt wrote:
>>
>> On 2012-04-10 14:53, Daniel D. Daugherty wrote:
>>> On 4/10/12 3:47 PM, Dmitry Samersoff wrote:
>>>
>>>> 1.
>>>>
>>>> 239 # If Full Debug Symbols is enabled, then we want the same debug and
>>>> 240 # optimization flags as used by FASTDEBUG. We also want all the
>>>> 241 # debug info in one place (-xs).
>>>>
>>>> Sorry! I'm later at the party. What is the reason of enforcing
>>>> certain optimization level with FDS?
>>>
>>> FDS doesn't enforce a certain optimization level. FDS takes advantage
>>> of work that other people have done to find optimization levels that
>>> work with fastdebug builds. This isn't so much an issue with the JDK
>>> (that I know of), but it is an issue with HotSpot. With HotSpot,
>>> fastdebug builds often use a lower optimization level than fully
>>> optimized builds because the compiler can't handle it. When FDS is
>>> enabled, we're basically doing a fastdebug build so we piggy back
>>> off of the same settings.
>>
>> Sorry for being a bit slow here, but I'm still not sure I understand
>> the comment. Can you clarify how the build process works and where the
>> FASTDEBUG optimization flags are used?
>
> In a FULL_DEBUG_SYMBOLS=0 build, the system works as it did before
> which means that OPT and FASTDEBUG flavor builds have their own set
> of compiler flags. So when you are doing an OPT build (the default),
> there is a default set of compiler flags. Of course, compiler flags
> can be overridden on a per-file basis for cases when the compiler
> with the default options is found to be buggy with a particular file.
> Similarly a FASTDEBUG build has a different set of default compiler
> flags and the default can also be overridden on a per-file basis.
>
> In a FULL_DEBUG_SYMBOLS=1 build, we override the OPT default set of
> compiler flags with the FASTDEBUG default set of compiler flags.
> This is because an FULL_DEBUG_SYMBOLS=1 build is pretty much the
> same as a FASTDEBUG build.
>
> Just to complete the picture, there is a master build flag for
> building the entire JDK with a DEBUG flavor. That build option is
> pretty much a sledgehammer that turns off any optimizations and
> enables full debug options. I have no idea if anyone even uses
> that build option anymore.
>
> Of course, HotSpot is different. HotSpot has FASTDEBUG, but instead
> of OPT it has PRODUCT. And HotSpot has a number of other build flavors,
> e.g., DEBUG, OPTIMIZED, PROFILED, ...
>
> Dan
>
>
>
>
>>
>> Thanks,
>> Mikael
>>
>>>
>>>
>>>> 2.
>>>> 192 ifeq ($(ENABLE_FULL_DEBUG_SYMBOLS),1)
>>>> 193 ifeq ($(ZIP_DEBUGINFO_FILES),1)
>>>> 194 (set -e ; \
>>>> 195 $(CD) $(OBJDIR) ; \
>>>> 196 $(ZIPEXE) -q $(PROGRAM).diz $(PROGRAM).map $(PROGRAM).pdb ; \
>>>> 197 $(RM) $(PROGRAM).map $(PROGRAM).pdb ; \
>>>> 198 )
>>>> 199 endif
>>>> 200 endif
>>>>
>>>>
>>>> No fallback on zip error here. No ideas what we should do if zip
>>>> fails, so it just a FYI.
>>>
>>> The 'set -e' on line 194 means that the build will fail. That is
>>> intentional. If the command fails unexpectedly, then the build
>>> should fail and hopefully with a useful error message.
>>>
>>> Dan
>>>
>>>
>>>>
>>>> -Dmitry
>>>>
>>>>
>>>> On 2012-04-11 01:17, Daniel D. Daugherty wrote:
>>>>> Thanks Serguei!
>>>>>
>>>>> Dan
>>>>>
>>>>>
>>>>> On 4/10/12 2:51 PM, serguei.spitsyn at oracle.com wrote:
>>>>>> Dan,
>>>>>>
>>>>>> It is good.
>>>>>>
>>>>>> Thanks,
>>>>>> Serguei
>>>>>>
>>>>>> On 4/9/12 1:51 PM, Daniel D. Daugherty wrote:
>>>>>>> Greetings,
>>>>>>>
>>>>>>> Coming soon to a JDK repo near you! Full Debug Symbols!
>>>>>>>
>>>>>>> OK, to just a subset of libraries and programs... on Linux and
>>>>>>> Solaris...
>>>>>>> If you're a Windows fan, the JDK repo has had Full Debug Symbols
>>>>>>> support
>>>>>>> since way back in JDK1.4.1... Now we're trying get Linux and Solaris
>>>>>>> caught up...
>>>>>>>
>>>>>>> Runtime Team, we don't have much in the JDK repo, but I tried to
>>>>>>> cover
>>>>>>> our few libraries and programs. Let me know if I missed anything...
>>>>>>>
>>>>>>> Serviceability Team, all of your demos, libraries and programs are
>>>>>>> covered... for some reason, updating those seemed like reliving old
>>>>>>> times and I didn't think you'd mind... :-)
>>>>>>>
>>>>>>> Here is the webrev URL:
>>>>>>>
>>>>>>> http://cr.openjdk.java.net/~dcubed/fds_revamp/7071907-webrev/0-jdk8-jdk/
>>>>>>>
>>>>>>>
>>>>>>> Thanks, in advance, for any review comments.
>>>>>>>
>>>>>>> Dan
>>>>>>>
>>>>>>> P.S.
>>>>>>> For those of you that are keeping track of all the FDS
>>>>>>> changesets, not everything has hit the various master
>>>>>>> repos yet. As a reminder, FDS has to hit the closed
>>>>>>> install repo first. The open root and jdk repos along
>>>>>>> with the closed deploy repo are in the second wave. And
>>>>>>> the hotspot repo, being more Mercurial than his fellow
>>>>>>> ghosts, will make his appearance in his own good time
>>>>>>> (and via a different set of repos)...
>>>>>>>
>>>>>>> Apologies to Dickens, of course... :-)
>>>>>>>
>>>>>>
>>>>
>>>>
>>


-- 
Dmitry Samersoff
Java Hotspot development team, SPB04
* There will come soft rains ...