RFR: JDK-8152666: The new Hotspot Build System

Daniel D. Daugherty daniel.daugherty at oracle.com
Tue Apr 5 18:10:04 UTC 2016 

On 3/25/16 2:03 AM, Erik Joelsson wrote:
> Hello,
>
> Here is the initial review for the new Hotspot Build System, as 
> described in " JEP 284: New HotSpot Build System". This patch adds the 
> new build system along side the old and makes the new system the 
> default. The old build system will remain for a (hopefully) short 
> while until we feel confident it is no longer needed. This enables us 
> to iron out any details that we might have missed with minimal 
> disruption for the users. The goal is to remove the old system after 
> one week of the new going in. During that time, both build systems 
> will have to be kept in sync. For that to be possible, all changes 
> touching anything in the make directory need to be reviewed by me.
>
> In this patch, the makefiles for the new build system are located in 
> hotspot/makefiles. When we apply the second phase, where we remove the 
> old build system, the new will move into the proper hotspot/make 
> directory.
>
> To activate the old build system after this patch has been applied, 
> use the configure arg "--disable-new-hotspot-build".
>
> For more information about how the new build works and how to interact 
> with it, Magnus wrote a document that is still relevant:
> http://hg.openjdk.java.net/build-infra/jdk9/file/tip/support/new-hotspot-build.md 
>

 > The hotspot build differs from all other libraries in the JDK in that the
 > library is (potentially) built multiple times with different 
conditions (-D
 > flags, for instance). The most common combination is building both 
the 'client'
 > and 'server' variant, but other combinations are possible. While this 
state of
 > affairs is not universally appreciated :-), it still is a use case 
that we need
 > to support, and it affects the entire build system for hotspot.

Thanks for the humor and for retaining this important difference in
the way HotSpot builds versus more sane/simple systems.


 > The new build supports the following variants:
 >
 >  * server (C1+C2)

The above "server" variant is the "tiered server". Does the new
build system support the "C2 server" variant? What about the
32-bit server and 64-bit server build variants? For example,
on Linux you can have:

   * C1/Client, 32-bit
   * C2/Server, 32-bit
   * Tiered (C1 & C2), 32-bit
   * C2/Server, 64-bit
   * Tiered (C1 + C2), 64-bit

The above wide range of variants is also true for Win*.

> The main method of verification for this patch has been running the 
> compare.sh script to verify that the output is equivalent to the old 
> build in as many cases as possible. In most configurations we have 
> reached a high level of confidence that we produce equivalent 
> binaries, but there are some exceptions that should be mentioned:
>
> * Solaris sparcv9 slowdebug produces differences when comparing 
> disassembly output from libjvm.so. I have not been able to find any 
> meaningful differences in compiler or linker flags to explain this.
> * Windows server jvm.dll ends up with some functions in different 
> order in the disassembly output. From what I can tell, the bits are 
> otherwise equivalent.
>
> We have also run the runtime nightlies with no notable failures.
>
> This is a pretty big patch and I expect it to take some time to get 
> properly reviewed. It contains contributions from Magnus Ihse Bursie, 
> Erik Joelsson and Ingemar Åberg.
>
> Bug: https://bugs.openjdk.java.net/browse/JDK-8152666
> Webrev: http://cr.openjdk.java.net/~erikj/8152666/webrev.01/index.html

General
Please make sure all the copyrights are updated.


common/autoconf/basics.m4
     No comments.

common/autoconf/build-performance.m4
     No comments.

common/autoconf/buildjdk-spec.gmk.in
     No comments.

common/autoconf/compare.sh.in
     No comments.

common/autoconf/configure
     No comments.

common/autoconf/configure.ac
     No comments.

common/autoconf/flags.m4
     L274:         SHARED_LIBRARY_FLAGS="-dynamiclib 
-compatibility_version 1.0.0 -current_version 1.0.0 $PICFLAG"
     L275:         JVM_CFLAGS="$JVM_CFLAGS -fPIC"

         L275 is new, but seeing it next to L274 makes me wonder if
         $PICFLAG should be used instead of the literal '-fPIC'?

     L303:         JVM_CFLAGS="$JVM_CFLAGS -fPIC"
         Same question about literal '-fPIC'.

     For most of the changes to flags.m4, I can't see how any of it
     relates to the new HotSpot build.

     Update: Now I'm wondering if this is one of those files that
         we typically don't review because it is auto generated.
         Sorry, don't remember for sure.

common/autoconf/generated-configure.sh
     2642 lines changed... I think this is one of those files
     you're supposed to skip in build-dev review... :-|

common/autoconf/help.m4
     L179:     $PRINTF "Which are valid to use depends on the target 
platform.\n  "
     L180:     $PRINTF "%s " $VALID_JVM_FEATURES
         Why are there blanks after the last '\n' on L179 instead of
         at the beginning of L180?

common/autoconf/hotspot-spec.gmk.in
     No comments.

common/autoconf/hotspot.m4
     L46: # Check if the specified JVM features are explicitely enabled. 
To be used in
         Typo: 'explicitely' -> 'explicitly'

     L59: #   server: normal interpreter, and a tiered C1/C2 compiler
         So no support for a C2-only server config?

     L77:   # Have the user listed more than one variant?
         Typo: 'Have' -> 'Has'

common/autoconf/jdk-options.m4
     No comments other than to say thanks for keeping support
     for 'optimized' builds.

common/autoconf/jdk-version.m4
     No comments.

common/autoconf/lib-std.m4
     No comments.

common/autoconf/libraries.m4
     No comments.

common/autoconf/platform.m4
     No comments, but mind numbing amount of diffs.

common/autoconf/spec.gmk.in
     No comments.

common/autoconf/toolchain.m4
     No comments.

common/autoconf/version-numbers
     No comments.

common/bin/compare.sh
     No comments.

common/bin/compare_exceptions.sh.incl
     No comments.

make/Jprt.gmk
     No comments.

make/Main.gmk
     No comments other than the 'hotspot-ide-project' target
     looks interesting...

make/common/MakeBase.gmk
     No comments.

make/common/NativeCompilation.gmk
     L649:   else ifeq (LOW, $$($1_OPTIMIZATION))
     L650:     $1_OPT_CFLAGS := $(C_O_FLAG_NORM)
     L651:     $1_OPT_CXXFLAGS := $(CXX_O_FLAG_NORM)
         Instead of "_NORM", I was expecting "_LOW".

     L652:   else ifeq (HIGH, $$($1_OPTIMIZATION))
     L653:     $1_OPT_CFLAGS := $(C_O_FLAG_HI)
     L654:     $1_OPT_CXXFLAGS := $(CXX_O_FLAG_HI)
         Instead of "_HI" I was expecting "_HIGH".

make/jprt.properties
     L136: # Don't disable precompiled headers on windows. It's simply 
too slow.
         This is a surprise. Not the slowness part, but not being
         able to do a non-PCH JPRT build on Win*. IMHO, it's a
         little  too much motherhood...

jdk/make/Import.gmk
     No comments.

jdk/make/copy/Copy-java.base.gmk
     No comments.

jdk/make/lib/CoreLibraries.gmk
     No comments.

hotspot/makefiles/BuildHotspot.gmk
     No comments.

hotspot/makefiles/Dist.gmk
     L52: define macosx_universalize
         I thought MacOS X universal support was going away?

         Update: OK, I see the mention of 8069540 ahead...

     L120: # these files are identical, and just pick one arbitrarily to 
use as souce.
         Typo: 'souce' -> 'source'

     L139: # This might have been defined in a custom extenstion
         Typo: 'extenstion' -> 'extension'

     L168: # NOTE: In the old build, this file was not copied on Windows.
     L169: ifneq ($(OPENJDK_TARGET_OS), windows)
     L170:   $(eval $(call SetupCopyFiles, COPY_JVMTI_HTML, \
         I'm not quite sure why the jvmti.html work is done for
         more than a single platform.

         Update: Thinking about this more... I vaguely remember that
         JVM/TI tracing used to be disabled in Client VMs. Don't know
         if that's still the case.

hotspot/makefiles/HotspotCommon.gmk
     No comments.

hotspot/makefiles/gensrc/GenerateSources.gmk
     No comments.

hotspot/makefiles/gensrc/GensrcAdlc.gmk
     L98:     # NOTE: Windows adlc flags was different in the old build. 
Is this really
     L99:     # correct?
         John Rose may know the answer to this historical question.

hotspot/makefiles/gensrc/GensrcDtrace.gmk
     No comments.

hotspot/makefiles/gensrc/GensrcJvmti.gmk
     No comments.

hotspot/makefiles/ide/CreateVSProject.gmk
     No comments.

hotspot/makefiles/lib/CompileDtracePostJvm.gmk
     No comments.

hotspot/makefiles/lib/CompileDtracePreJvm.gmk
     No comments.

hotspot/makefiles/lib/CompileJvm.gmk
     No comments.

hotspot/makefiles/lib/CompileLibjsig.gmk
     No comments.

hotspot/makefiles/lib/CompileLibraries.gmk
     No comments.

hotspot/makefiles/lib/JvmFeatures.gmk
     No comments.

hotspot/makefiles/lib/JvmMapfile.gmk
     No comments.

hotspot/makefiles/lib/JvmOverrideFiles.gmk
     No comments.

hotspot/makefiles/mapfiles/libjsig/mapfile-vers-solaris
hotspot/makefiles/mapfiles/libjvm_db/mapfile-vers
hotspot/makefiles/mapfiles/libjvm_dtrace/mapfile-vers
     No comments on the mapfiles.

hotspot/makefiles/symbols/symbols-aix
hotspot/makefiles/symbols/symbols-aix-debug
hotspot/makefiles/symbols/symbols-linux
hotspot/makefiles/symbols/symbols-macosx
hotspot/makefiles/symbols/symbols-shared
hotspot/makefiles/symbols/symbols-solaris
hotspot/makefiles/symbols/symbols-solaris-dtrace-compiler1
hotspot/makefiles/symbols/symbols-solaris-dtrace-compiler2
hotspot/makefiles/symbols/symbols-unix
     No comments on the symbol files.


Thumbs up on this fix; I don't think that anything I noted
above is a show stopper for this changeset.

Dan


>
> /Erik

More information about the build-dev mailing list