code review request for initial JDK FDS support (7071907)

Thu Apr 12 14:44:33 UTC 2012

On 4/12/12 8:39 AM, Dmitry Samersoff wrote:
> Dan,
>
> We link two semantically different options together and it make me 
> uncomfortable with this fix.

This JDK fix has the exact same semantics as the HotSpot
changes that I did for FDS. As I keep saying over and over
and over, a Full Debug Symbols build is pretty much the same
thing as Fastdebug build. If you want FDS, you have to give
up some optimizations.

> 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.

Dan

>
> -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... :-)
>>>>>>>>
>>>>>>>
>>>>>
>>>>>
>>>
>
>