RFR(S): 8027480 - Build Windows x64 fastdebug builds using /homeparams
Daniel D. Daugherty
daniel.daugherty at oracle.com
Wed Aug 20 17:28:18 UTC 2014
Your call.
Dan
On 8/20/14 11:05 AM, Christian Tornqvist wrote:
> I talked to Staffan Friberg (perf tech lead) about enabling this in a
> release builds and this is his opinion:
>
> "For /homeparams I think enable it now in fastdebug, let's use it for a
> while and understand home much of a benefit it is for debugging. If it is a
> huge help let's consider it for release, but that will require a lot of
> performance testing before commiting"
>
> I agree with Staffan and think we should only enable it in fastdebug builds
> for now.
>
> Thanks,
> Christian
>
> -----Original Message-----
> From: Daniel D. Daugherty [mailto:daniel.daugherty at oracle.com]
> Sent: Wednesday, August 20, 2014 12:02 PM
> To: Christian Tornqvist
> Cc: hotspot-dev at openjdk.java.net; build-dev at openjdk.java.net
> Subject: Re: RFR(S): 8027480 - Build Windows x64 fastdebug builds using
> /homeparams
>
> On 8/20/14 9:48 AM, Christian Tornqvist wrote:
>>> indicate that we shouldn't need this change in our debug/fastdebug
> builds.
>> However, you looked at the generated prologue code before and after
>> turning on this option right?
>>
>> Our fastdebug builds are compiled with /O2 which doesn't spill the
>> parameters onto the stack, our debug builds (with /Od) will do this so
>> passing /homeparams there is a no-op.
>>
>> Here is a look at the prologue code for
>> ClassFileParser::parse_constant_pool_entries() before /homeparams:
>>
>> mov dword ptr [rsp+10h],edx
>> push rbp
>> push rsi
>>
>> and here is with /homeparams:
>>
>> mov qword ptr [rsp+18h],r8
>> mov dword ptr [rsp+10h],edx
>> mov qword ptr [rsp+8],rcx
>> push rbp
>> push rsi
> Cool. When we did the Full Debug Symbols (FDS) project, one of the things we
> did was try to use the same optimization and debug options with
> RELEASE/product builds as with fastdebug builds. Since we're generating
> debug info for all builds configs, we thought this was a really good design
> goal unless we ran into a performance issue.
>
> During the FDS project, we saw no performance change when we switched the
> optimization options and included the various generate-debug-info options.
>
> A long way of saying:
>
> I think you should enable /homeparams for RELEASE/product builds.
>
> :-)
>
> Dan
>
>
>> Thanks,
>> Christian
>>
>> -----Original Message-----
>> From: Daniel D. Daugherty [mailto:daniel.daugherty at oracle.com]
>> Sent: Wednesday, August 20, 2014 11:17 AM
>> To: Christian Tornqvist
>> Cc: hotspot-dev at openjdk.java.net; build-dev at openjdk.java.net
>> Subject: Re: RFR(S): 8027480 - Build Windows x64 fastdebug builds
>> using /homeparams
>>
>> On 8/20/14 8:49 AM, Christian Tornqvist wrote:
>>>> Do we have any idea how much of a change? Do we care? I'm presuming
>>>> the
>>> increased debuggability is worth it.
>>>
>>> It adds 0-4 additional stack movs in function prologue code which
>>> should have a very low impact, it's only on debug/fastdebug builds.
>> I missed that this was a non-RELEASE build change in my original review.
>>
>> These two blurbs from the MSDN note:
>>
>> > However, by default in a release build, the register parameters >
>> will not be written to the stack, into the space that is already >
>> provided for the parameters. This makes it difficult to debug an >
>> optimized (release) build of your program.
>>
>> and
>>
>> > In a debug build, the stack is always populated with parameters >
>> passed in registers.
>>
>> indicate that we shouldn't need this change in our debug/fastdebug builds.
>> However, you looked at the generated prologue code before and after
>> turning on this option right?
>>
>> Does this mean that the MSDN note is not correct for the way that we
>> do debug and fastdebug builds? We might have some option enabled that
>> prevents the default /homeparams behavior from working...
>>
>> Dan
>>
>>
>>>> The above block will also apply to an "ia64" build. We don't support
>>>> that
>>> anymore, but I don't know if any licensees support it.
>>>
>>> I've changed the checks in vm.make and WinGammaPlatformVC10.java
>>>
>>>> Do we need to do anything about the new, but unused platform to
>>>> make
>>> lint-like tools not squawk?
>>>
>>> I'll open a new bug to clean up the VC7/8/9 files in ProjectCreator.
>>>
>>> New webrev:
>>> http://cr.openjdk.java.net/~ctornqvi/webrev/8027480/webrev.01/
>>>
>>> Thanks,
>>> Christian
>>>
>>> -----Original Message-----
>>> From: Daniel D. Daugherty [mailto:daniel.daugherty at oracle.com]
>>> Sent: Wednesday, August 20, 2014 9:48 AM
>>> To: Christian Tornqvist
>>> Cc: hotspot-dev at openjdk.java.net
>>> Subject: Re: RFR(S): 8027480 - Build Windows x64 fastdebug builds
>>> using /homeparams
>>>
>>> > http://cr.openjdk.java.net/~ctornqvi/webrev/8027480/webrev.00/
>>>
>>> General Comment
>>>
>>> The MSDN note says:
>>>
>>> > /homeparams does imply a performance disadvantage, because it >
>>> does require a cycle to load the register parameters on to the stack.
>>>
>>> Do we have any idea how much of a change? Do we care? I'm presuming
>>> the increased debuggability is worth it.
>>>
>>> make/windows/makefiles/vm.make
>>> line 38: !else
>>> line 39: CXX_FLAGS=$(CXX_FLAGS) /D "ASSERT" /homeparams
>>> line 40: !endif
>>> The above block will also apply to an "ia64" build.
>>> We don't support that anymore, but I don't know if
>>> any licensees support it.
>>>
>>> src/share/tools/ProjectCreator/BuildConfig.java
>>> No comments.
>>>
>>> src/share/tools/ProjectCreator/WinGammaPlatformVC10.java
>>> line 373: if(!platformName.equals("Win32")) {
>>> line 374: addAttr(rv, "AdditionalOptions", "/homeparams");
>>> The above block will also apply to an "ia64" build.
>>>
>>> src/share/tools/ProjectCreator/WinGammaPlatformVC7.java
>>> src/share/tools/ProjectCreator/WinGammaPlatformVC8.java
>>> Do we need to do anything about the new, but unused
>>> platform to make lint-like tools not squawk?
>>>
>>> Thumbs up.
>>>
>>> Dan
>>>
>>>
>>> On 8/19/14 5:39 PM, Christian Tornqvist wrote:
>>>> Hi everyone,
>>>>
>>>>
>>>>
>>>> This change adds /homeparams
>>>> (http://msdn.microsoft.com/en-us/library/6exwh0y6.aspx) to compiler
>>>> flags when building fastdebug on Windows x64. This causes the
>>>> compiler to generate code to spill the first 4 arguments to the
>>>> stack (they're normally only passed in registers), which should make
>>>> it easier
>> to debug.
>>>>
>>>>
>>>> I also changed the ProjectCreator to enable building with this using
>>>> Visual Studio. The size of jvm.dll increases with about 3% (about
>>>> 504k
>>> increase).
>>>>
>>>>
>>>> Verified that it builds correctly using Visual Studio and JPRT, the
>>>> generation of the spill code has been verified by comparing prologue
>>>> code for several functions in the JVM with/without using /homeparams.
>>>>
>>>>
>>>>
>>>> Webrev:
>>>>
>>>> http://cr.openjdk.java.net/~ctornqvi/webrev/8027480/webrev.00/
>>>>
>>>>
>>>>
>>>> Bug:
>>>>
>>>> https://bugs.openjdk.java.net/browse/JDK-8027480
>>>>
>>>>
>>>>
>>>> Thanks,
>>>>
>>>> Christian
>>>>
>>>>
>>>>
>
More information about the build-dev
mailing list