code review request for initial JDK FDS support (7071907)

[Daniel D. Daugherty]

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