RFR(S): 8027480 - Build Windows x64 fastdebug builds using /homeparams
Christian Tornqvist
christian.tornqvist at oracle.com
Wed Aug 20 17:05:02 UTC 2014
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