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.daughe...@oracle.com] Sent: Wednesday, August 20, 2014 12:02 PM To: Christian Tornqvist Cc: hotspot-...@openjdk.java.net; build-dev@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.daughe...@oracle.com] > Sent: Wednesday, August 20, 2014 11:17 AM > To: Christian Tornqvist > Cc: hotspot-...@openjdk.java.net; build-dev@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.daughe...@oracle.com] >> Sent: Wednesday, August 20, 2014 9:48 AM >> To: Christian Tornqvist >> Cc: hotspot-...@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 >>> >>> >>> >
