code review request for initial JDK FDS support (7071907)
Dmitry Samersoff
Dmitry.Samersoff at oracle.com
Thu Apr 12 14:46:48 UTC 2012
Dan,
OK. Sorry for disturbing you.
-Dmitry
On 2012-04-12 18:44, Daniel D. Daugherty wrote:
> 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... :-)
>>>>>>>>>
>>>>>>>>
>>>>>>
>>>>>>
>>>>
>>
>>
--
Dmitry Samersoff
Java Hotspot development team, SPB04
* There will come soft rains ...
More information about the build-dev
mailing list