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



Reply via email to