> 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 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 >> >> >> >
