Re: RFR: 8209093 - JEP 340: One AArch64 Port, Not Two
Hi Simon, On 20/09/2018 7:48 AM, Simon Nash wrote: On 19/09/2018 07:44, David Holmes wrote: Hi Bob, On 18/09/2018 11:17 PM, Bob Vandette wrote: I only did some basic testing of the hard-float abi. Bell SW has offered to do more extensive testing as part of this JEP. I have no way of knowing if any of the other profiles are being used but I would think it’s worth keeping them in the event that someone wants to try to build/test these other configurations. The goal of this JEP is to eliminate the arm64 port and not cause any other changes in behavior. Sorry I was under the mistaken impression that all of the Oracle ARM port was being removed, but it is only the 64-bit part. That said it would concern me greatly if people are still building for anything older than ARMv7 with MP support! The work I'm doing to always act as-if MP is not only potentially inefficient on a uniprocessor, but for ARM variants without MP support, potentially it won't even run if instructions don't exist. I need to look into this further. Thanks, David David, My build for arm-sflt needs to run on ARMv5 uniprocessor maschines and my build for arm-vfp-hflt needs to run on ARMv7 uniprocessor machines. Is the work you are doing that could cause problems with this included in JDK11 or just JDK12? This is for JDK 12. Of course the intent is to not cause problems for anyone. The changes aim at simplifying the code whilst marginally improving performance in the common case of a multi-processor system, at the expense of potentially decreasing performance for uniprocessors. Though as has been pointed out in my review thread, the existing use of AssumeMP (default true) will be causing the same performance changes and for spinlocks my changes will improve things for uniprocessors. My area of concern is where instructions issued for the MP case may not be valid on specific architectures. For example pldw is only available on ARMv7 with multi-processor extensions. I need to be sure, for example, only supported DMB/DSB variants are issued on ARMv5. Thanks, David Simon Bob. On Sep 17, 2018, at 10:53 PM, David Holmes wrote: Hi Bob, On 18/09/2018 2:20 AM, Bob Vandette wrote: Please review the changes related to JEP 340 which remove the second 64-bit ARM port from the JDK. http://cr.openjdk.java.net/~bobv/8209093/webrev.01 I’ve testing building the remaining 32 and 64 bit ARM ports including the minimal, client and server VMs. I’ve run specJVM98 on the three 32-bit ARM VMs. Did you test all the ARM related abi-profiles? It seems to me they were only for Oracle's ARM32 port and may have never been used otherwise. I would have expected all that stuff to be removed. Cheers, David I also verified that Linux x64 builds. Bob.
RFR: JDK-8210988 Improved handling of compiler warnings in the build
This is the first part towards a better framework in the build for handling compiler warnings. The basic idea is that we should have consistent way for all compilers to: 1) enable all (relevant) warnings 2) disable individual warnings, on a global scale (if 1 enables too much) In particular, this means unifying the basic set of enabled warnings between hotspot and the JDK native libraries. From that starting point, warnings can be disabled on a per-library fashion, if it does not make sense for that specific library. (Like how it's done today, but more consistently performed.) This first part will just put most of the infrastructure in place, and strives to keep exactly the same warnings enabled or disabled for all code. Bug: https://bugs.openjdk.java.net/browse/JDK-8210988 WebRev: http://cr.openjdk.java.net/~ihse/JDK-8210988-improved-warning-flags-handling/webrev.01 /Magnus
Re: RFR: JDK-8210962 Deprecate jdk-variant
Looks good. /Erik On 2018-09-20 11:42, Magnus Ihse Bursie wrote: On 2018-09-20 19:47, Erik Joelsson wrote: On 2018-09-20 10:24, Magnus Ihse Bursie wrote: On 2018-09-20 18:59, Aleksey Shipilev wrote: On 09/20/2018 06:48 PM, Magnus Ihse Bursie wrote: A long time ago, we supported different "variants" of the JDK build, like "normal" and "embedded". The --with-jdk-variant and associated machinery has been kept in place, even though it's not doing anyting. Time to remove it. I chose to keep the "-normal-" in the build output name so as not to break any scripts. But I'm willing to change this if someone has a clear opinion otherwise. This breakage would happen at some point anyway, unless we accept that "-normal-" would linger forever. It is probably for the best to break it when we purge the configure option. I concur with Alexsey and say we remove it with the option. For me, removing this is the biggest improvement. :) Ok, I hear you. :-) Here is an updated webrev, where I remove the "-normal-" part of the build output name. http://cr.openjdk.java.net/~ihse/JDK-8210962-deprecate-jdk-variant/webrev.02 Let's discuss any further changes to the build output name separately. I'll see if I can whip up some prototype and then we can prod it around a bit until we are all satisfied. /Magnus I'm actually not very fond of the build output name format, and have considered changing it drastically for some time. Maybe this should be the time. Currently the default format looks like this: "linux-x86_64-normal-server-release", that is . The selection of these configuration parameters feels a bit arbitrary. Some examples of other parameters we could have included, but don't, are: abi-profile, jvm-features, version-string, static-build, headless-only. The relevance of including any of these parameters in the build output name depends on some thought-up scenario were the alternative configurations that reasonably could be built at the same time. For instance, in a cross-compilation scenario, os and cpu makes sense to include, but perhaps not otherwise. The jvm-variant is more or less reduced to server or zero at this time, and it's unclear if this needs to be part of the build output directory name. When building with the Oracle jib tool, we get profiles named like "linux-x64" or "linux-x64-debug". To me, this is not such a mouthful as the default configure name. Or perhaps we should have names that are more dynamic? Just like the debug-level is either empty (for release) or "-debug" in the jib name, maybe we should skip elements if they have a default value? So linux-x86_64-zero would mean the JVM variant zero, but linux-x86_64 mean the JVM variant server (default)? And linux-x86_64-zero-static_build-headless_only-fastdebug would be just that... A problem with empty default, which I often curse myself for in the case of the jib named output dirs, is that if you have both linux-x64 and linux-x64-debug, you can't easily pick linux-x64 with "make CONF=", you have to work around it by doing "make CONF_NAME=linux-x64", which is very annoying. I regret that naming convention for this reason. On the other hand, we cannot have an arbitrarily large tuple all the time either. I think that -- would be the most common base and that you could add additional parts for other parameters if they deviate from defaults, or perhaps if they are explicitly set, even if matching the default. Several of the parameters you mention above would be good candidates for conditionally changing the output dir. /Erik
Re: RFR: JDK-8210931 JLI and launchers normalization and cleanup
Looks ok. /Erik On 2018-09-20 01:32, Magnus Ihse Bursie wrote: There's a lot of weird stuff going on with libjli and the launchers. Most of it stems from the old build system, which was just copied verbatim into the new build system. This is the final part of getting JLI to behave like most other libraries. This patch will: * store libjli in the standard lib directory, not in a "jli" subdirectory. * remove dead code for filtering ergo files, which do no longer exist * use file extension to show type (ObjectiveC), rather than -x objective-c. * use more common constructs in setting up the native compilation arguments. * clean out unused flags and arguments. Bug: https://bugs.openjdk.java.net/browse/JDK-8210931 WebRev: http://cr.openjdk.java.net/~ihse/JDK-8210931-jli-normalization/webrev.01 /Magnus
Re: RFR: JDK-8210962 Deprecate jdk-variant
On 2018-09-20 19:47, Erik Joelsson wrote: On 2018-09-20 10:24, Magnus Ihse Bursie wrote: On 2018-09-20 18:59, Aleksey Shipilev wrote: On 09/20/2018 06:48 PM, Magnus Ihse Bursie wrote: A long time ago, we supported different "variants" of the JDK build, like "normal" and "embedded". The --with-jdk-variant and associated machinery has been kept in place, even though it's not doing anyting. Time to remove it. I chose to keep the "-normal-" in the build output name so as not to break any scripts. But I'm willing to change this if someone has a clear opinion otherwise. This breakage would happen at some point anyway, unless we accept that "-normal-" would linger forever. It is probably for the best to break it when we purge the configure option. I concur with Alexsey and say we remove it with the option. For me, removing this is the biggest improvement. :) Ok, I hear you. :-) Here is an updated webrev, where I remove the "-normal-" part of the build output name. http://cr.openjdk.java.net/~ihse/JDK-8210962-deprecate-jdk-variant/webrev.02 Let's discuss any further changes to the build output name separately. I'll see if I can whip up some prototype and then we can prod it around a bit until we are all satisfied. /Magnus I'm actually not very fond of the build output name format, and have considered changing it drastically for some time. Maybe this should be the time. Currently the default format looks like this: "linux-x86_64-normal-server-release", that is . The selection of these configuration parameters feels a bit arbitrary. Some examples of other parameters we could have included, but don't, are: abi-profile, jvm-features, version-string, static-build, headless-only. The relevance of including any of these parameters in the build output name depends on some thought-up scenario were the alternative configurations that reasonably could be built at the same time. For instance, in a cross-compilation scenario, os and cpu makes sense to include, but perhaps not otherwise. The jvm-variant is more or less reduced to server or zero at this time, and it's unclear if this needs to be part of the build output directory name. When building with the Oracle jib tool, we get profiles named like "linux-x64" or "linux-x64-debug". To me, this is not such a mouthful as the default configure name. Or perhaps we should have names that are more dynamic? Just like the debug-level is either empty (for release) or "-debug" in the jib name, maybe we should skip elements if they have a default value? So linux-x86_64-zero would mean the JVM variant zero, but linux-x86_64 mean the JVM variant server (default)? And linux-x86_64-zero-static_build-headless_only-fastdebug would be just that... A problem with empty default, which I often curse myself for in the case of the jib named output dirs, is that if you have both linux-x64 and linux-x64-debug, you can't easily pick linux-x64 with "make CONF=", you have to work around it by doing "make CONF_NAME=linux-x64", which is very annoying. I regret that naming convention for this reason. On the other hand, we cannot have an arbitrarily large tuple all the time either. I think that -- would be the most common base and that you could add additional parts for other parameters if they deviate from defaults, or perhaps if they are explicitly set, even if matching the default. Several of the parameters you mention above would be good candidates for conditionally changing the output dir. /Erik
Re: RFR: JDK-8210962 Deprecate jdk-variant
On 2018-09-20 11:35, Aleksey Shipilev wrote: I guess the question is how much variability is there in day-to-day builds. As the guy who builds lots of different configurations, I see great simplicity in maintaining current static label that captures most of the usual variability. For example, my current scripts have: build_dir_base = 'build/' + os + '-' + target_oj + '-normal-' + variant + '-' + mode + '/' The only oddity here is "normal", which I would be happy to see going, even if this requires me to special case jdk-12+ build configs. Just a side note, you know about --with-conf-name? If I was automating various builds I would probably want to be in control of the outputdir instead of trying to predict it. /Erik
Re: RFR: JDK-8210962 Deprecate jdk-variant
On 09/20/2018 07:24 PM, Magnus Ihse Bursie wrote: > Currently the default format looks like this: > "linux-x86_64-normal-server-release", that is > . The selection of these > configuration > parameters feels a bit arbitrary. Some examples of other parameters we could > have included, but > don't, are: abi-profile, jvm-features, version-string, static-build, > headless-only. > > The relevance of including any of these parameters in the build output name > depends on some > thought-up scenario were the alternative configurations that reasonably could > be built at the same > time. For instance, in a cross-compilation scenario, os and cpu makes sense > to include, but perhaps > not otherwise. The jvm-variant is more or less reduced to server or zero at > this time, and it's > unclear if this needs to be part of the build output directory name. I guess the question is how much variability is there in day-to-day builds. As the guy who builds lots of different configurations, I see great simplicity in maintaining current static label that captures most of the usual variability. For example, my current scripts have: build_dir_base = 'build/' + os + '-' + target_oj + '-normal-' + variant + '-' + mode + '/' The only oddity here is "normal", which I would be happy to see going, even if this requires me to special case jdk-12+ build configs. Granted, scripts could be changed to accept whatever configuration label we come up with. I do not see any benefit of including the version-string (the really dynamic parameter?), that would justify additional work in build scripts. jvm-features-wise, I think most builders stick with the static set of features anyway. Headless/headful might be interesting, but I guess most builders do not care about headless anyway. ABI is interesting, but different-ABI-ed builds are is probably built in separate containers/machines anyway. -Aleksey
Re: RFR: JDK-8210962 Deprecate jdk-variant
On 2018-09-20 10:24, Magnus Ihse Bursie wrote: On 2018-09-20 18:59, Aleksey Shipilev wrote: On 09/20/2018 06:48 PM, Magnus Ihse Bursie wrote: A long time ago, we supported different "variants" of the JDK build, like "normal" and "embedded". The --with-jdk-variant and associated machinery has been kept in place, even though it's not doing anyting. Time to remove it. I chose to keep the "-normal-" in the build output name so as not to break any scripts. But I'm willing to change this if someone has a clear opinion otherwise. This breakage would happen at some point anyway, unless we accept that "-normal-" would linger forever. It is probably for the best to break it when we purge the configure option. I concur with Alexsey and say we remove it with the option. For me, removing this is the biggest improvement. :) I'm actually not very fond of the build output name format, and have considered changing it drastically for some time. Maybe this should be the time. Currently the default format looks like this: "linux-x86_64-normal-server-release", that is . The selection of these configuration parameters feels a bit arbitrary. Some examples of other parameters we could have included, but don't, are: abi-profile, jvm-features, version-string, static-build, headless-only. The relevance of including any of these parameters in the build output name depends on some thought-up scenario were the alternative configurations that reasonably could be built at the same time. For instance, in a cross-compilation scenario, os and cpu makes sense to include, but perhaps not otherwise. The jvm-variant is more or less reduced to server or zero at this time, and it's unclear if this needs to be part of the build output directory name. When building with the Oracle jib tool, we get profiles named like "linux-x64" or "linux-x64-debug". To me, this is not such a mouthful as the default configure name. Or perhaps we should have names that are more dynamic? Just like the debug-level is either empty (for release) or "-debug" in the jib name, maybe we should skip elements if they have a default value? So linux-x86_64-zero would mean the JVM variant zero, but linux-x86_64 mean the JVM variant server (default)? And linux-x86_64-zero-static_build-headless_only-fastdebug would be just that... A problem with empty default, which I often curse myself for in the case of the jib named output dirs, is that if you have both linux-x64 and linux-x64-debug, you can't easily pick linux-x64 with "make CONF=", you have to work around it by doing "make CONF_NAME=linux-x64", which is very annoying. I regret that naming convention for this reason. On the other hand, we cannot have an arbitrarily large tuple all the time either. I think that -- would be the most common base and that you could add additional parts for other parameters if they deviate from defaults, or perhaps if they are explicitly set, even if matching the default. Several of the parameters you mention above would be good candidates for conditionally changing the output dir. /Erik
Re: RFR: JDK-8210962 Deprecate jdk-variant
On 2018-09-20 18:59, Aleksey Shipilev wrote: On 09/20/2018 06:48 PM, Magnus Ihse Bursie wrote: A long time ago, we supported different "variants" of the JDK build, like "normal" and "embedded". The --with-jdk-variant and associated machinery has been kept in place, even though it's not doing anyting. Time to remove it. I chose to keep the "-normal-" in the build output name so as not to break any scripts. But I'm willing to change this if someone has a clear opinion otherwise. This breakage would happen at some point anyway, unless we accept that "-normal-" would linger forever. It is probably for the best to break it when we purge the configure option. I'm actually not very fond of the build output name format, and have considered changing it drastically for some time. Maybe this should be the time. Currently the default format looks like this: "linux-x86_64-normal-server-release", that is . The selection of these configuration parameters feels a bit arbitrary. Some examples of other parameters we could have included, but don't, are: abi-profile, jvm-features, version-string, static-build, headless-only. The relevance of including any of these parameters in the build output name depends on some thought-up scenario were the alternative configurations that reasonably could be built at the same time. For instance, in a cross-compilation scenario, os and cpu makes sense to include, but perhaps not otherwise. The jvm-variant is more or less reduced to server or zero at this time, and it's unclear if this needs to be part of the build output directory name. When building with the Oracle jib tool, we get profiles named like "linux-x64" or "linux-x64-debug". To me, this is not such a mouthful as the default configure name. Or perhaps we should have names that are more dynamic? Just like the debug-level is either empty (for release) or "-debug" in the jib name, maybe we should skip elements if they have a default value? So linux-x86_64-zero would mean the JVM variant zero, but linux-x86_64 mean the JVM variant server (default)? And linux-x86_64-zero-static_build-headless_only-fastdebug would be just that... /Magnus Bug: https://bugs.openjdk.java.net/browse/JDK-8210962 WebRev: http://cr.openjdk.java.net/~ihse/JDK-8210962-deprecate-jdk-variant/webrev.01 Ah, my heart skipped a bit. It is important to mention this is _not_ jvm-variant :) $ sh ./configure --help | grep variant --with-jdk-variant JDK variant to build (normal) [normal] <--- removing this guy --with-jvm-variants JVM variants (separated by commas) to build configure: The available JVM variants are: "server client minimal core zero custom" Thanks, -Aleksey
Re: RFR: JDK-8210962 Deprecate jdk-variant
On 09/20/2018 06:48 PM, Magnus Ihse Bursie wrote: > A long time ago, we supported different "variants" of the JDK build, like > "normal" and "embedded". > The --with-jdk-variant and associated machinery has been kept in place, even > though it's not doing > anyting. Time to remove it. > > I chose to keep the "-normal-" in the build output name so as not to break > any scripts. But I'm > willing to change this if someone has a clear opinion otherwise. This breakage would happen at some point anyway, unless we accept that "-normal-" would linger forever. It is probably for the best to break it when we purge the configure option. > Bug: https://bugs.openjdk.java.net/browse/JDK-8210962 > WebRev: > http://cr.openjdk.java.net/~ihse/JDK-8210962-deprecate-jdk-variant/webrev.01 Ah, my heart skipped a bit. It is important to mention this is _not_ jvm-variant :) $ sh ./configure --help | grep variant --with-jdk-variant JDK variant to build (normal) [normal] <--- removing this guy --with-jvm-variants JVM variants (separated by commas) to build configure: The available JVM variants are: "server client minimal core zero custom" Thanks, -Aleksey
RFR: JDK-8210962 Deprecate jdk-variant
A long time ago, we supported different "variants" of the JDK build, like "normal" and "embedded". The --with-jdk-variant and associated machinery has been kept in place, even though it's not doing anyting. Time to remove it. I chose to keep the "-normal-" in the build output name so as not to break any scripts. But I'm willing to change this if someone has a clear opinion otherwise. Bug: https://bugs.openjdk.java.net/browse/JDK-8210962 WebRev: http://cr.openjdk.java.net/~ihse/JDK-8210962-deprecate-jdk-variant/webrev.01 /Magnus
Re: [8u] RFR: 8210350: -Wl,-z,defs JDK 8 build failure
Looks good to me. /Erik On 2018-09-20 08:09, Severin Gehwolf wrote: Hi, Could someone please review this JDK 8u only change. When building with extra linker flags, namely -Wl,-z,defs, the build fails on linux in the serviciability agent. The reason for this is missing -ldl on the link command. Note that JDK 9+ with the new build system have that already. Thoughts? Bug: https://bugs.openjdk.java.net/browse/JDK-8210350 webrev: http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8210350/webrev.01/ Thanks, Severin
Re: RFR: JDK-8210960 Allow --with-boot-jdk-jvmargs to work during configure
Hello, Looks good. /Erik On 2018-09-20 04:43, Magnus Ihse Bursie wrote: Allow --with-boot-jdk-jvmargs to work during the configure phase. Also report the usages of _JAVA_OPTIONS and JAVA_TOOL_OPTIONS environment variables, which can seriously mess up the build. Bug: https://bugs.openjdk.java.net/browse/JDK-8210960 WebRev: http://cr.openjdk.java.net/~ihse/JDK-8210960-use-with-boot-jdk-jvmargs-in-configure/webrev.01 /Magnus
Re: RFR: JDK-8210949 Stop filtering out -xc99=%none for liblcms
Looks good. /Erik On 2018-09-20 01:35, Magnus Ihse Bursie wrote: We're currently filtering out -xc99=%none from CFLAGS_JDKLIB in liblcms. We do not need to to this. Appending -xc99=no_lib using CFLAGS_solaris is enough to override. Bug: https://bugs.openjdk.java.net/browse/JDK-8210949 Patch inline: diff --git a/make/lib/Awt2dLibraries.gmk b/make/lib/Awt2dLibraries.gmk --- a/make/lib/Awt2dLibraries.gmk +++ b/make/lib/Awt2dLibraries.gmk @@ -357,8 +357,6 @@ # The fast floor code loses precision. LCMS_CFLAGS=-DCMS_DONT_USE_FAST_FLOOR -LCMS_CFLAGS_JDKLIB := $(filter-out -xc99=%none, $(CFLAGS_JDKLIB)) - ifeq ($(USE_EXTERNAL_LCMS), true) # If we're using an external library, we'll just need the wrapper part. # By including it explicitly, all other files will be excluded. @@ -374,7 +372,7 @@ NAME := lcms, \ INCLUDE_FILES := $(BUILD_LIBLCMS_INCLUDE_FILES), \ OPTIMIZATION := HIGHEST, \ - CFLAGS := $(LCMS_CFLAGS_JDKLIB) \ + CFLAGS := $(CFLAGS_JDKLIB) \ $(LCMS_CFLAGS), \ CFLAGS_solaris := -xc99=no_lib, \ CFLAGS_windows := -DCMS_IS_WINDOWS_, \ /Magnus
Re: RFR: JDK-8210944 Stop replacing -MD with -MT in libwindowsaccessbridge
Looks good. /Erik On 2018-09-20 00:05, Magnus Ihse Bursie wrote: Currently, we are filtering out -MD and replacing it with -MT when building libwindowsaccessbridge. This has just been a way to replicate the behavior of old build system, and there's no point in doing so. In fact, it is recommended *not* to mix -MT and -MD in dlls and executable, as that might lead to problems (as seen in e.g. JDK-8207139). Bug: https://bugs.openjdk.java.net/browse/JDK-8210944 Patch inline: diff --git a/make/lib/Lib-jdk.accessibility.gmk b/make/lib/Lib-jdk.accessibility.gmk --- a/make/lib/Lib-jdk.accessibility.gmk +++ b/make/lib/Lib-jdk.accessibility.gmk @@ -69,7 +69,7 @@ EXTRA_SRC := common, \ OPTIMIZATION := LOW, \ DISABLED_WARNINGS_microsoft := 4311 4302 4312, \ - CFLAGS := $(filter-out -MD, $(CFLAGS_JDKLIB)) -MT \ + CFLAGS := $(CFLAGS_JDKLIB) \ -DACCESSBRIDGE_ARCH_$2, \ EXTRA_HEADER_DIRS := \ include/bridge \ /Magnus
Re: RFR: JDK-8210941 Stop filtering out -xregs=no%appl for libsunec
Looks good. /Erik On 2018-09-19 23:44, Magnus Ihse Bursie wrote: We have been filtering out the -xregs=no%appl when compiling libsunec for sparc. This is just an remnant of the old build system, where this were not properly set. (The recommendation is to use it for dlls.) To mimic the old behavior, we chose to filter it out when converting the old build system. But there's really no point in keeping it. Bug: https://bugs.openjdk.java.net/browse/JDK-8210941 WebRev: http://cr.openjdk.java.net/~ihse/JDK-8210941-stop-filter-xregs-no-appl-on-libsunec/webrev.01 /Magnus
[8u] RFR: 8210350: -Wl,-z,defs JDK 8 build failure
Hi, Could someone please review this JDK 8u only change. When building with extra linker flags, namely -Wl,-z,defs, the build fails on linux in the serviciability agent. The reason for this is missing -ldl on the link command. Note that JDK 9+ with the new build system have that already. Thoughts? Bug: https://bugs.openjdk.java.net/browse/JDK-8210350 webrev: http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8210350/webrev.01/ Thanks, Severin
Re: How to pass additional options to boot jdk during configure, _JAVA_OPTIONS does not work
On Thu, Sep 20, 2018 at 7:36 PM Magnus Ihse Bursie wrote: > > On 2018-09-20 12:41, Ao Qi wrote: > > On Thu, Sep 20, 2018 at 4:10 PM Magnus Ihse Bursie > wrote: > > On 2018-09-20 09:26, Ao Qi wrote: > > Hi, > > Is there any options or methods that I can pass additional jdk options > to the boot jdk when I configure jdk/jdk? I found > --with-boot-jdk-jvmargs, but I think it is effective during building > the jdk, not configuring the jdk. > > You are correct, the additional arguments in --with-boot-jdk-jvmargs is only > used during the build, not during configure. > > I used _JAVA_OPTIONS, but it failed to configure (fail to detect jdk > version). I made a patch: > > $ hg diff > diff -r feb4c9e03aed make/autoconf/basics.m4 > --- a/make/autoconf/basics.m4 Tue Sep 18 19:44:27 2018 -0700 > +++ b/make/autoconf/basics.m4 Wed Sep 19 11:44:54 2018 +0800 > @@ -168,7 +168,7 @@ > [ >$ECHO "Check if jvm arg is ok: $1" >_MESSAGE_LOG_FD >$ECHO "Command: $3 $1 -version" >_MESSAGE_LOG_FD > - OUTPUT=`$3 $1 -version 2>&1` > + OUTPUT=`$3 $1 -version 2>&1 | $GREP -v "^Picked up _JAVA_OPTIONS:"` >FOUND_WARN=`$ECHO "$OUTPUT" | $GREP -i warn` >FOUND_VERSION=`$ECHO $OUTPUT | $GREP " version \""` >if test "x$FOUND_VERSION" != x && test "x$FOUND_WARN" = x; then > diff -r feb4c9e03aed make/autoconf/boot-jdk.m4 > --- a/make/autoconf/boot-jdk.m4 Tue Sep 18 19:44:27 2018 -0700 > +++ b/make/autoconf/boot-jdk.m4 Wed Sep 19 11:44:54 2018 +0800 > @@ -74,7 +74,7 @@ >BOOT_JDK_FOUND=no > else ># Oh, this is looking good! We probably have found a proper > JDK. Is it the correct version? > - BOOT_JDK_VERSION=`"$BOOT_JDK/bin/java" -version 2>&1 | $HEAD -n 1` > + BOOT_JDK_VERSION=`"$BOOT_JDK/bin/java" -version 2>&1 | > $GREP -v "^Picked up _JAVA_OPTIONS:" | $HEAD -n 1` > ># Extra M4 quote needed to protect [] in grep expression. >[FOUND_CORRECT_VERSION=`$ECHO $BOOT_JDK_VERSION \ > @@ -90,7 +90,7 @@ > AC_MSG_CHECKING([for Boot JDK]) > AC_MSG_RESULT([$BOOT_JDK]) > AC_MSG_CHECKING([Boot JDK version]) > -BOOT_JDK_VERSION=`"$BOOT_JDK/bin/java" -version 2>&1 | > $TR '\n\r' ' '` > +BOOT_JDK_VERSION=`"$BOOT_JDK/bin/java" -version 2>&1 | > $GREP -v "^Picked up _JAVA_OPTIONS:" | $TR '\n\r' ' '` > AC_MSG_RESULT([$BOOT_JDK_VERSION]) >fi # end check jdk version > fi # end check javac > > > > This works for me. The _JAVA_OPTIONS is effective during configure. Is > there some other way to do that (without changing the code)? Or > otherwise is it possible to accept this patch? > > Hm. Using _JAVA_OPTIONS is really not good. It's a very hidden way to > influence the behavior of a running Java process. It might fail if it is not > accepted on both the boot JDK and the newly built JDK. > > I think a better solution would be to add the --with-boot-jdk-jvmargs to the > boot JDK version check. > > Here's an alternative patch. Please try it out and see if it works for you. > It will apply the --with-boot-jdk-jvmargs at all calls to Java. > > This patch works for me, and it passed my test script. Thanks! If this > patch is intended to push into jdk/jdk, just one minor thing: is > JAVA_TOOL_OPTIONS also needed to be considered? > > I didn't even know there was a JAVA_TOOL_OPTIONS. :) Yes, we should handle > that as well. I'll update the patch and put it out for review. Thanks! > I didn't know it either. I was cruise and grep _JAVA_OPTIONS in hotspot, and found that there is a JAVA_TOOL_OPTIONS. :) Ao Qi > /Magnus > > > Cheers, > Ao Qi > > diff --git a/make/autoconf/basics.m4 b/make/autoconf/basics.m4 > --- a/make/autoconf/basics.m4 > +++ b/make/autoconf/basics.m4 > @@ -168,7 +168,7 @@ > [ >$ECHO "Check if jvm arg is ok: $1" >_MESSAGE_LOG_FD >$ECHO "Command: $3 $1 -version" >_MESSAGE_LOG_FD > - OUTPUT=`$3 $1 -version 2>&1` > + OUTPUT=`$3 $1 $USER_BOOT_JDK_OPTIONS -version 2>&1` >FOUND_WARN=`$ECHO "$OUTPUT" | $GREP -i warn` >FOUND_VERSION=`$ECHO $OUTPUT | $GREP " version \""` >if test "x$FOUND_VERSION" != x && test "x$FOUND_WARN" = x; then > diff --git a/make/autoconf/boot-jdk.m4 b/make/autoconf/boot-jdk.m4 > --- a/make/autoconf/boot-jdk.m4 > +++ b/make/autoconf/boot-jdk.m4 > @@ -74,7 +74,17 @@ >BOOT_JDK_FOUND=no > else ># Oh, this is looking good! We probably have found a proper JDK. > Is it the correct version? > - BOOT_JDK_VERSION=`"$BOOT_JDK/bin/java" -version 2>&1 | $HEAD -n 1` > + BOOT_JDK_VERSION=`"$BOOT_JDK/bin/java" $USER_BOOT_JDK_OPTIONS > -version 2>&1 | $HEAD -n 1` > + if [ [[ "$BOOT_JDK_VERSION" =~ "Picked up _JAVA_OPTIONS" ]] ]; then > +AC_MSG_NOTICE([You have _JAVA_OPTIONS set. This can mess up the > build. Please use --with-boot-jdk-jvmargs instead.]) > +AC_MSG_ERROR([Cannot continue]) > + fi > + if [ [[ "$BOOT_JDK_VERSION" =~
Re: RFR: JDK-8210931 JLI and launchers normalization and cleanup
On 20/09/2018 12:31, Magnus Ihse Bursie wrote: I'm pretty sure I've run at least the instrument tests, but I'll rerun it just to make sure. Does :jdk_instrument and :jdk_launcher sound reasonable? Yes that will run them. At some point I hope we can get the JPLIS agent in libinstrument changed to not have the dependency on JLI but that will require work. What is the current dependency due to? (Just curious) Java Agents are configured by attributes in the main manifest of their JAR file and libjli has the native support to do the parsing. This is why it is linked against libz too. -Alan
Re: RFR: 8209093 - JEP 340: One AArch64 Port, Not Two
On 19/09/2018 07:44, David Holmes wrote: Hi Bob, On 18/09/2018 11:17 PM, Bob Vandette wrote: I only did some basic testing of the hard-float abi. Bell SW has offered to do more extensive testing as part of this JEP. I have no way of knowing if any of the other profiles are being used but I would think it’s worth keeping them in the event that someone wants to try to build/test these other configurations. The goal of this JEP is to eliminate the arm64 port and not cause any other changes in behavior. Sorry I was under the mistaken impression that all of the Oracle ARM port was being removed, but it is only the 64-bit part. That said it would concern me greatly if people are still building for anything older than ARMv7 with MP support! The work I'm doing to always act as-if MP is not only potentially inefficient on a uniprocessor, but for ARM variants without MP support, potentially it won't even run if instructions don't exist. I need to look into this further. Thanks, David David, My build for arm-sflt needs to run on ARMv5 uniprocessor maschines and my build for arm-vfp-hflt needs to run on ARMv7 uniprocessor machines. Is the work you are doing that could cause problems with this included in JDK11 or just JDK12? Simon Bob. On Sep 17, 2018, at 10:53 PM, David Holmes wrote: Hi Bob, On 18/09/2018 2:20 AM, Bob Vandette wrote: Please review the changes related to JEP 340 which remove the second 64-bit ARM port from the JDK. http://cr.openjdk.java.net/~bobv/8209093/webrev.01 I’ve testing building the remaining 32 and 64 bit ARM ports including the minimal, client and server VMs. I’ve run specJVM98 on the three 32-bit ARM VMs. Did you test all the ARM related abi-profiles? It seems to me they were only for Oracle's ARM32 port and may have never been used otherwise. I would have expected all that stuff to be removed. Cheers, David I also verified that Linux x64 builds. Bob.
RFR: JDK-8210960 Allow --with-boot-jdk-jvmargs to work during configure
Allow --with-boot-jdk-jvmargs to work during the configure phase. Also report the usages of _JAVA_OPTIONS and JAVA_TOOL_OPTIONS environment variables, which can seriously mess up the build. Bug: https://bugs.openjdk.java.net/browse/JDK-8210960 WebRev: http://cr.openjdk.java.net/~ihse/JDK-8210960-use-with-boot-jdk-jvmargs-in-configure/webrev.01 /Magnus
Re: How to pass additional options to boot jdk during configure, _JAVA_OPTIONS does not work
On 2018-09-20 12:41, Ao Qi wrote: On Thu, Sep 20, 2018 at 4:10 PM Magnus Ihse Bursie wrote: On 2018-09-20 09:26, Ao Qi wrote: Hi, Is there any options or methods that I can pass additional jdk options to the boot jdk when I configure jdk/jdk? I found --with-boot-jdk-jvmargs, but I think it is effective during building the jdk, not configuring the jdk. You are correct, the additional arguments in --with-boot-jdk-jvmargs is only used during the build, not during configure. I used _JAVA_OPTIONS, but it failed to configure (fail to detect jdk version). I made a patch: $ hg diff diff -r feb4c9e03aed make/autoconf/basics.m4 --- a/make/autoconf/basics.m4 Tue Sep 18 19:44:27 2018 -0700 +++ b/make/autoconf/basics.m4 Wed Sep 19 11:44:54 2018 +0800 @@ -168,7 +168,7 @@ [ $ECHO "Check if jvm arg is ok: $1" >_MESSAGE_LOG_FD $ECHO "Command: $3 $1 -version" >_MESSAGE_LOG_FD - OUTPUT=`$3 $1 -version 2>&1` + OUTPUT=`$3 $1 -version 2>&1 | $GREP -v "^Picked up _JAVA_OPTIONS:"` FOUND_WARN=`$ECHO "$OUTPUT" | $GREP -i warn` FOUND_VERSION=`$ECHO $OUTPUT | $GREP " version \""` if test "x$FOUND_VERSION" != x && test "x$FOUND_WARN" = x; then diff -r feb4c9e03aed make/autoconf/boot-jdk.m4 --- a/make/autoconf/boot-jdk.m4 Tue Sep 18 19:44:27 2018 -0700 +++ b/make/autoconf/boot-jdk.m4 Wed Sep 19 11:44:54 2018 +0800 @@ -74,7 +74,7 @@ BOOT_JDK_FOUND=no else # Oh, this is looking good! We probably have found a proper JDK. Is it the correct version? - BOOT_JDK_VERSION=`"$BOOT_JDK/bin/java" -version 2>&1 | $HEAD -n 1` + BOOT_JDK_VERSION=`"$BOOT_JDK/bin/java" -version 2>&1 | $GREP -v "^Picked up _JAVA_OPTIONS:" | $HEAD -n 1` # Extra M4 quote needed to protect [] in grep expression. [FOUND_CORRECT_VERSION=`$ECHO $BOOT_JDK_VERSION \ @@ -90,7 +90,7 @@ AC_MSG_CHECKING([for Boot JDK]) AC_MSG_RESULT([$BOOT_JDK]) AC_MSG_CHECKING([Boot JDK version]) -BOOT_JDK_VERSION=`"$BOOT_JDK/bin/java" -version 2>&1 | $TR '\n\r' ' '` +BOOT_JDK_VERSION=`"$BOOT_JDK/bin/java" -version 2>&1 | $GREP -v "^Picked up _JAVA_OPTIONS:" | $TR '\n\r' ' '` AC_MSG_RESULT([$BOOT_JDK_VERSION]) fi # end check jdk version fi # end check javac This works for me. The _JAVA_OPTIONS is effective during configure. Is there some other way to do that (without changing the code)? Or otherwise is it possible to accept this patch? Hm. Using _JAVA_OPTIONS is really not good. It's a very hidden way to influence the behavior of a running Java process. It might fail if it is not accepted on both the boot JDK and the newly built JDK. I think a better solution would be to add the --with-boot-jdk-jvmargs to the boot JDK version check. Here's an alternative patch. Please try it out and see if it works for you. It will apply the --with-boot-jdk-jvmargs at all calls to Java. This patch works for me, and it passed my test script. Thanks! If this patch is intended to push into jdk/jdk, just one minor thing: is JAVA_TOOL_OPTIONS also needed to be considered? I didn't even know there was a JAVA_TOOL_OPTIONS. :) Yes, we should handle that as well. I'll update the patch and put it out for review. Thanks! /Magnus Cheers, Ao Qi diff --git a/make/autoconf/basics.m4 b/make/autoconf/basics.m4 --- a/make/autoconf/basics.m4 +++ b/make/autoconf/basics.m4 @@ -168,7 +168,7 @@ [ $ECHO "Check if jvm arg is ok: $1" >_MESSAGE_LOG_FD $ECHO "Command: $3 $1 -version" >_MESSAGE_LOG_FD - OUTPUT=`$3 $1 -version 2>&1` + OUTPUT=`$3 $1 $USER_BOOT_JDK_OPTIONS -version 2>&1` FOUND_WARN=`$ECHO "$OUTPUT" | $GREP -i warn` FOUND_VERSION=`$ECHO $OUTPUT | $GREP " version \""` if test "x$FOUND_VERSION" != x && test "x$FOUND_WARN" = x; then diff --git a/make/autoconf/boot-jdk.m4 b/make/autoconf/boot-jdk.m4 --- a/make/autoconf/boot-jdk.m4 +++ b/make/autoconf/boot-jdk.m4 @@ -74,7 +74,17 @@ BOOT_JDK_FOUND=no else # Oh, this is looking good! We probably have found a proper JDK. Is it the correct version? - BOOT_JDK_VERSION=`"$BOOT_JDK/bin/java" -version 2>&1 | $HEAD -n 1` + BOOT_JDK_VERSION=`"$BOOT_JDK/bin/java" $USER_BOOT_JDK_OPTIONS -version 2>&1 | $HEAD -n 1` + if [ [[ "$BOOT_JDK_VERSION" =~ "Picked up _JAVA_OPTIONS" ]] ]; then +AC_MSG_NOTICE([You have _JAVA_OPTIONS set. This can mess up the build. Please use --with-boot-jdk-jvmargs instead.]) +AC_MSG_ERROR([Cannot continue]) + fi + if [ [[ "$BOOT_JDK_VERSION" =~ "Unrecognized option" ]] ]; then +AC_MSG_NOTICE([The specified --with-boot-jdk-jvmargs is invalid for the tested java]) +AC_MSG_NOTICE([Error message: "$BOOT_JDK_VERSION".]) +AC_MSG_NOTICE([Please fix arguments, or point to an explicit boot JDK which accept these arguments]) +AC_MSG_ERROR([Cannot continue]) + fi
Re: RFR: JDK-8210931 JLI and launchers normalization and cleanup
On 2018-09-20 13:24, Alan Bateman wrote: On 20/09/2018 09:32, Magnus Ihse Bursie wrote: There's a lot of weird stuff going on with libjli and the launchers. Most of it stems from the old build system, which was just copied verbatim into the new build system. This is the final part of getting JLI to behave like most other libraries. This patch will: * store libjli in the standard lib directory, not in a "jli" subdirectory. * remove dead code for filtering ergo files, which do no longer exist * use file extension to show type (ObjectiveC), rather than -x objective-c. * use more common constructs in setting up the native compilation arguments. * clean out unused flags and arguments. Bug: https://bugs.openjdk.java.net/browse/JDK-8210931 WebRev: http://cr.openjdk.java.net/~ihse/JDK-8210931-jli-normalization/webrev.01 This looks okay to me but I think would be useful to confirm that you've run the tools/launcher and java.lang.instrument tests. I'm pretty sure I've run at least the instrument tests, but I'll rerun it just to make sure. Does :jdk_instrument and :jdk_launcher sound reasonable? At some point I hope we can get the JPLIS agent in libinstrument changed to not have the dependency on JLI but that will require work. What is the current dependency due to? (Just curious) /Magnus -Alan
RFR: JDK-8210958 Rename "make run-test" to "make test"
The time has come to start phasing out the old test running framework
("cd test && make"). This patch will change the behavior of "make test"
to use the new run-test framework, instead of the old.
The old framework is still available as of now by using "cd test && make".
The "run-test" target (and variants like exploded-run-test or
run-test-tier1) are kept as aliases.
Using "cd test && make" will result in a warning being printed that it
is recommended to stop using this way of running tests.
Bug: https://bugs.openjdk.java.net/browse/JDK-8210958
WebRev:
http://cr.openjdk.java.net/~ihse/JDK-8210958-rename-run-test-to-test/webrev.01
/Magnus
Re: How to pass additional options to boot jdk during configure, _JAVA_OPTIONS does not work
On Thu, Sep 20, 2018 at 4:10 PM Magnus Ihse Bursie wrote: > > On 2018-09-20 09:26, Ao Qi wrote: > > Hi, > > Is there any options or methods that I can pass additional jdk options > to the boot jdk when I configure jdk/jdk? I found > --with-boot-jdk-jvmargs, but I think it is effective during building > the jdk, not configuring the jdk. > > You are correct, the additional arguments in --with-boot-jdk-jvmargs is only > used during the build, not during configure. > > I used _JAVA_OPTIONS, but it failed to configure (fail to detect jdk > version). I made a patch: > > $ hg diff > diff -r feb4c9e03aed make/autoconf/basics.m4 > --- a/make/autoconf/basics.m4 Tue Sep 18 19:44:27 2018 -0700 > +++ b/make/autoconf/basics.m4 Wed Sep 19 11:44:54 2018 +0800 > @@ -168,7 +168,7 @@ > [ >$ECHO "Check if jvm arg is ok: $1" >_MESSAGE_LOG_FD >$ECHO "Command: $3 $1 -version" >_MESSAGE_LOG_FD > - OUTPUT=`$3 $1 -version 2>&1` > + OUTPUT=`$3 $1 -version 2>&1 | $GREP -v "^Picked up _JAVA_OPTIONS:"` >FOUND_WARN=`$ECHO "$OUTPUT" | $GREP -i warn` >FOUND_VERSION=`$ECHO $OUTPUT | $GREP " version \""` >if test "x$FOUND_VERSION" != x && test "x$FOUND_WARN" = x; then > diff -r feb4c9e03aed make/autoconf/boot-jdk.m4 > --- a/make/autoconf/boot-jdk.m4 Tue Sep 18 19:44:27 2018 -0700 > +++ b/make/autoconf/boot-jdk.m4 Wed Sep 19 11:44:54 2018 +0800 > @@ -74,7 +74,7 @@ >BOOT_JDK_FOUND=no > else ># Oh, this is looking good! We probably have found a proper > JDK. Is it the correct version? > - BOOT_JDK_VERSION=`"$BOOT_JDK/bin/java" -version 2>&1 | $HEAD -n 1` > + BOOT_JDK_VERSION=`"$BOOT_JDK/bin/java" -version 2>&1 | > $GREP -v "^Picked up _JAVA_OPTIONS:" | $HEAD -n 1` > ># Extra M4 quote needed to protect [] in grep expression. >[FOUND_CORRECT_VERSION=`$ECHO $BOOT_JDK_VERSION \ > @@ -90,7 +90,7 @@ > AC_MSG_CHECKING([for Boot JDK]) > AC_MSG_RESULT([$BOOT_JDK]) > AC_MSG_CHECKING([Boot JDK version]) > -BOOT_JDK_VERSION=`"$BOOT_JDK/bin/java" -version 2>&1 | > $TR '\n\r' ' '` > +BOOT_JDK_VERSION=`"$BOOT_JDK/bin/java" -version 2>&1 | > $GREP -v "^Picked up _JAVA_OPTIONS:" | $TR '\n\r' ' '` > AC_MSG_RESULT([$BOOT_JDK_VERSION]) >fi # end check jdk version > fi # end check javac > > > > This works for me. The _JAVA_OPTIONS is effective during configure. Is > there some other way to do that (without changing the code)? Or > otherwise is it possible to accept this patch? > > Hm. Using _JAVA_OPTIONS is really not good. It's a very hidden way to > influence the behavior of a running Java process. It might fail if it is not > accepted on both the boot JDK and the newly built JDK. > > I think a better solution would be to add the --with-boot-jdk-jvmargs to the > boot JDK version check. > > Here's an alternative patch. Please try it out and see if it works for you. > It will apply the --with-boot-jdk-jvmargs at all calls to Java. > This patch works for me, and it passed my test script. Thanks! If this patch is intended to push into jdk/jdk, just one minor thing: is JAVA_TOOL_OPTIONS also needed to be considered? Cheers, Ao Qi > diff --git a/make/autoconf/basics.m4 b/make/autoconf/basics.m4 > --- a/make/autoconf/basics.m4 > +++ b/make/autoconf/basics.m4 > @@ -168,7 +168,7 @@ > [ >$ECHO "Check if jvm arg is ok: $1" >_MESSAGE_LOG_FD >$ECHO "Command: $3 $1 -version" >_MESSAGE_LOG_FD > - OUTPUT=`$3 $1 -version 2>&1` > + OUTPUT=`$3 $1 $USER_BOOT_JDK_OPTIONS -version 2>&1` >FOUND_WARN=`$ECHO "$OUTPUT" | $GREP -i warn` >FOUND_VERSION=`$ECHO $OUTPUT | $GREP " version \""` >if test "x$FOUND_VERSION" != x && test "x$FOUND_WARN" = x; then > diff --git a/make/autoconf/boot-jdk.m4 b/make/autoconf/boot-jdk.m4 > --- a/make/autoconf/boot-jdk.m4 > +++ b/make/autoconf/boot-jdk.m4 > @@ -74,7 +74,17 @@ >BOOT_JDK_FOUND=no > else ># Oh, this is looking good! We probably have found a proper JDK. > Is it the correct version? > - BOOT_JDK_VERSION=`"$BOOT_JDK/bin/java" -version 2>&1 | $HEAD -n 1` > + BOOT_JDK_VERSION=`"$BOOT_JDK/bin/java" $USER_BOOT_JDK_OPTIONS > -version 2>&1 | $HEAD -n 1` > + if [ [[ "$BOOT_JDK_VERSION" =~ "Picked up _JAVA_OPTIONS" ]] ]; then > +AC_MSG_NOTICE([You have _JAVA_OPTIONS set. This can mess up the > build. Please use --with-boot-jdk-jvmargs instead.]) > +AC_MSG_ERROR([Cannot continue]) > + fi > + if [ [[ "$BOOT_JDK_VERSION" =~ "Unrecognized option" ]] ]; then > +AC_MSG_NOTICE([The specified --with-boot-jdk-jvmargs is invalid > for the tested java]) > +AC_MSG_NOTICE([Error message: "$BOOT_JDK_VERSION".]) > +AC_MSG_NOTICE([Please fix arguments, or point to an explicit > boot JDK which accept these arguments]) > +AC_MSG_ERROR([Cannot continue]) > + fi > ># Extra M4
RFR: JDK-8210949 Stop filtering out -xc99=%none for liblcms
We're currently filtering out -xc99=%none from CFLAGS_JDKLIB in liblcms. We do not need to to this. Appending -xc99=no_lib using CFLAGS_solaris is enough to override. Bug: https://bugs.openjdk.java.net/browse/JDK-8210949 Patch inline: diff --git a/make/lib/Awt2dLibraries.gmk b/make/lib/Awt2dLibraries.gmk --- a/make/lib/Awt2dLibraries.gmk +++ b/make/lib/Awt2dLibraries.gmk @@ -357,8 +357,6 @@ # The fast floor code loses precision. LCMS_CFLAGS=-DCMS_DONT_USE_FAST_FLOOR -LCMS_CFLAGS_JDKLIB := $(filter-out -xc99=%none, $(CFLAGS_JDKLIB)) - ifeq ($(USE_EXTERNAL_LCMS), true) # If we're using an external library, we'll just need the wrapper part. # By including it explicitly, all other files will be excluded. @@ -374,7 +372,7 @@ NAME := lcms, \ INCLUDE_FILES := $(BUILD_LIBLCMS_INCLUDE_FILES), \ OPTIMIZATION := HIGHEST, \ - CFLAGS := $(LCMS_CFLAGS_JDKLIB) \ + CFLAGS := $(CFLAGS_JDKLIB) \ $(LCMS_CFLAGS), \ CFLAGS_solaris := -xc99=no_lib, \ CFLAGS_windows := -DCMS_IS_WINDOWS_, \ /Magnus
RFR: JDK-8210931 JLI and launchers normalization and cleanup
There's a lot of weird stuff going on with libjli and the launchers. Most of it stems from the old build system, which was just copied verbatim into the new build system. This is the final part of getting JLI to behave like most other libraries. This patch will: * store libjli in the standard lib directory, not in a "jli" subdirectory. * remove dead code for filtering ergo files, which do no longer exist * use file extension to show type (ObjectiveC), rather than -x objective-c. * use more common constructs in setting up the native compilation arguments. * clean out unused flags and arguments. Bug: https://bugs.openjdk.java.net/browse/JDK-8210931 WebRev: http://cr.openjdk.java.net/~ihse/JDK-8210931-jli-normalization/webrev.01 /Magnus
Re: How to pass additional options to boot jdk during configure, _JAVA_OPTIONS does not work
On 2018-09-20 09:26, Ao Qi wrote: Hi, Is there any options or methods that I can pass additional jdk options to the boot jdk when I configure jdk/jdk? I found --with-boot-jdk-jvmargs, but I think it is effective during building the jdk, not configuring the jdk. You are correct, the additional arguments in --with-boot-jdk-jvmargs is only used during the build, not during configure. I used _JAVA_OPTIONS, but it failed to configure (fail to detect jdk version). I made a patch: $ hg diff diff -r feb4c9e03aed make/autoconf/basics.m4 --- a/make/autoconf/basics.m4 Tue Sep 18 19:44:27 2018 -0700 +++ b/make/autoconf/basics.m4 Wed Sep 19 11:44:54 2018 +0800 @@ -168,7 +168,7 @@ [ $ECHO "Check if jvm arg is ok: $1" >_MESSAGE_LOG_FD $ECHO "Command: $3 $1 -version" >_MESSAGE_LOG_FD - OUTPUT=`$3 $1 -version 2>&1` + OUTPUT=`$3 $1 -version 2>&1 | $GREP -v "^Picked up _JAVA_OPTIONS:"` FOUND_WARN=`$ECHO "$OUTPUT" | $GREP -i warn` FOUND_VERSION=`$ECHO $OUTPUT | $GREP " version \""` if test "x$FOUND_VERSION" != x && test "x$FOUND_WARN" = x; then diff -r feb4c9e03aed make/autoconf/boot-jdk.m4 --- a/make/autoconf/boot-jdk.m4 Tue Sep 18 19:44:27 2018 -0700 +++ b/make/autoconf/boot-jdk.m4 Wed Sep 19 11:44:54 2018 +0800 @@ -74,7 +74,7 @@ BOOT_JDK_FOUND=no else # Oh, this is looking good! We probably have found a proper JDK. Is it the correct version? - BOOT_JDK_VERSION=`"$BOOT_JDK/bin/java" -version 2>&1 | $HEAD -n 1` + BOOT_JDK_VERSION=`"$BOOT_JDK/bin/java" -version 2>&1 | $GREP -v "^Picked up _JAVA_OPTIONS:" | $HEAD -n 1` # Extra M4 quote needed to protect [] in grep expression. [FOUND_CORRECT_VERSION=`$ECHO $BOOT_JDK_VERSION \ @@ -90,7 +90,7 @@ AC_MSG_CHECKING([for Boot JDK]) AC_MSG_RESULT([$BOOT_JDK]) AC_MSG_CHECKING([Boot JDK version]) -BOOT_JDK_VERSION=`"$BOOT_JDK/bin/java" -version 2>&1 | $TR '\n\r' ' '` +BOOT_JDK_VERSION=`"$BOOT_JDK/bin/java" -version 2>&1 | $GREP -v "^Picked up _JAVA_OPTIONS:" | $TR '\n\r' ' '` AC_MSG_RESULT([$BOOT_JDK_VERSION]) fi # end check jdk version fi # end check javac This works for me. The _JAVA_OPTIONS is effective during configure. Is there some other way to do that (without changing the code)? Or otherwise is it possible to accept this patch? Hm. Using _JAVA_OPTIONS is really not good. It's a very hidden way to influence the behavior of a running Java process. It might fail if it is not accepted on both the boot JDK and the newly built JDK. I think a better solution would be to add the --with-boot-jdk-jvmargs to the boot JDK version check. Here's an alternative patch. Please try it out and see if it works for you. It will apply the --with-boot-jdk-jvmargs at all calls to Java. diff --git a/make/autoconf/basics.m4 b/make/autoconf/basics.m4 --- a/make/autoconf/basics.m4 +++ b/make/autoconf/basics.m4 @@ -168,7 +168,7 @@ [ $ECHO "Check if jvm arg is ok: $1" >_MESSAGE_LOG_FD $ECHO "Command: $3 $1 -version" >_MESSAGE_LOG_FD - OUTPUT=`$3 $1 -version 2>&1` + OUTPUT=`$3 $1 $USER_BOOT_JDK_OPTIONS -version 2>&1` FOUND_WARN=`$ECHO "$OUTPUT" | $GREP -i warn` FOUND_VERSION=`$ECHO $OUTPUT | $GREP " version \""` if test "x$FOUND_VERSION" != x && test "x$FOUND_WARN" = x; then diff --git a/make/autoconf/boot-jdk.m4 b/make/autoconf/boot-jdk.m4 --- a/make/autoconf/boot-jdk.m4 +++ b/make/autoconf/boot-jdk.m4 @@ -74,7 +74,17 @@ BOOT_JDK_FOUND=no else # Oh, this is looking good! We probably have found a proper JDK. Is it the correct version? - BOOT_JDK_VERSION=`"$BOOT_JDK/bin/java" -version 2>&1 | $HEAD -n 1` + BOOT_JDK_VERSION=`"$BOOT_JDK/bin/java" $USER_BOOT_JDK_OPTIONS -version 2>&1 | $HEAD -n 1` + if [ [[ "$BOOT_JDK_VERSION" =~ "Picked up _JAVA_OPTIONS" ]] ]; then + AC_MSG_NOTICE([You have _JAVA_OPTIONS set. This can mess up the build. Please use --with-boot-jdk-jvmargs instead.]) + AC_MSG_ERROR([Cannot continue]) + fi + if [ [[ "$BOOT_JDK_VERSION" =~ "Unrecognized option" ]] ]; then + AC_MSG_NOTICE([The specified --with-boot-jdk-jvmargs is invalid for the tested java]) + AC_MSG_NOTICE([Error message: "$BOOT_JDK_VERSION".]) + AC_MSG_NOTICE([Please fix arguments, or point to an explicit boot JDK which accept these arguments]) + AC_MSG_ERROR([Cannot continue]) + fi # Extra M4 quote needed to protect [] in grep expression. [FOUND_CORRECT_VERSION=`$ECHO $BOOT_JDK_VERSION \ @@ -90,7 +100,7 @@ AC_MSG_CHECKING([for Boot JDK]) AC_MSG_RESULT([$BOOT_JDK]) AC_MSG_CHECKING([Boot JDK version]) - BOOT_JDK_VERSION=`"$BOOT_JDK/bin/java" -version 2>&1 | $TR '\n\r' ' '` + BOOT_JDK_VERSION=`"$BOOT_JDK/bin/java" $USER_BOOT_JDK_OPTIONS -version 2>&1 |
How to pass additional options to boot jdk during configure, _JAVA_OPTIONS does not work
Hi, Is there any options or methods that I can pass additional jdk options to the boot jdk when I configure jdk/jdk? I found --with-boot-jdk-jvmargs, but I think it is effective during building the jdk, not configuring the jdk. I used _JAVA_OPTIONS, but it failed to configure (fail to detect jdk version). I made a patch: $ hg diff diff -r feb4c9e03aed make/autoconf/basics.m4 --- a/make/autoconf/basics.m4 Tue Sep 18 19:44:27 2018 -0700 +++ b/make/autoconf/basics.m4 Wed Sep 19 11:44:54 2018 +0800 @@ -168,7 +168,7 @@ [ $ECHO "Check if jvm arg is ok: $1" >_MESSAGE_LOG_FD $ECHO "Command: $3 $1 -version" >_MESSAGE_LOG_FD - OUTPUT=`$3 $1 -version 2>&1` + OUTPUT=`$3 $1 -version 2>&1 | $GREP -v "^Picked up _JAVA_OPTIONS:"` FOUND_WARN=`$ECHO "$OUTPUT" | $GREP -i warn` FOUND_VERSION=`$ECHO $OUTPUT | $GREP " version \""` if test "x$FOUND_VERSION" != x && test "x$FOUND_WARN" = x; then diff -r feb4c9e03aed make/autoconf/boot-jdk.m4 --- a/make/autoconf/boot-jdk.m4 Tue Sep 18 19:44:27 2018 -0700 +++ b/make/autoconf/boot-jdk.m4 Wed Sep 19 11:44:54 2018 +0800 @@ -74,7 +74,7 @@ BOOT_JDK_FOUND=no else # Oh, this is looking good! We probably have found a proper JDK. Is it the correct version? - BOOT_JDK_VERSION=`"$BOOT_JDK/bin/java" -version 2>&1 | $HEAD -n 1` + BOOT_JDK_VERSION=`"$BOOT_JDK/bin/java" -version 2>&1 | $GREP -v "^Picked up _JAVA_OPTIONS:" | $HEAD -n 1` # Extra M4 quote needed to protect [] in grep expression. [FOUND_CORRECT_VERSION=`$ECHO $BOOT_JDK_VERSION \ @@ -90,7 +90,7 @@ AC_MSG_CHECKING([for Boot JDK]) AC_MSG_RESULT([$BOOT_JDK]) AC_MSG_CHECKING([Boot JDK version]) -BOOT_JDK_VERSION=`"$BOOT_JDK/bin/java" -version 2>&1 | $TR '\n\r' ' '` +BOOT_JDK_VERSION=`"$BOOT_JDK/bin/java" -version 2>&1 | $GREP -v "^Picked up _JAVA_OPTIONS:" | $TR '\n\r' ' '` AC_MSG_RESULT([$BOOT_JDK_VERSION]) fi # end check jdk version fi # end check javac This works for me. The _JAVA_OPTIONS is effective during configure. Is there some other way to do that (without changing the code)? Or otherwise is it possible to accept this patch? Cheers, Ao Qi
RFR: JDK-8210944 Stop replacing -MD with -MT in libwindowsaccessbridge
Currently, we are filtering out -MD and replacing it with -MT when building libwindowsaccessbridge. This has just been a way to replicate the behavior of old build system, and there's no point in doing so. In fact, it is recommended *not* to mix -MT and -MD in dlls and executable, as that might lead to problems (as seen in e.g. JDK-8207139). Bug: https://bugs.openjdk.java.net/browse/JDK-8210944 Patch inline: diff --git a/make/lib/Lib-jdk.accessibility.gmk b/make/lib/Lib-jdk.accessibility.gmk --- a/make/lib/Lib-jdk.accessibility.gmk +++ b/make/lib/Lib-jdk.accessibility.gmk @@ -69,7 +69,7 @@ EXTRA_SRC := common, \ OPTIMIZATION := LOW, \ DISABLED_WARNINGS_microsoft := 4311 4302 4312, \ - CFLAGS := $(filter-out -MD, $(CFLAGS_JDKLIB)) -MT \ + CFLAGS := $(CFLAGS_JDKLIB) \ -DACCESSBRIDGE_ARCH_$2, \ EXTRA_HEADER_DIRS := \ include/bridge \ /Magnus
RFR: JDK-8210941 Stop filtering out -xregs=no%appl for libsunec
We have been filtering out the -xregs=no%appl when compiling libsunec for sparc. This is just an remnant of the old build system, where this were not properly set. (The recommendation is to use it for dlls.) To mimic the old behavior, we chose to filter it out when converting the old build system. But there's really no point in keeping it. Bug: https://bugs.openjdk.java.net/browse/JDK-8210941 WebRev: http://cr.openjdk.java.net/~ihse/JDK-8210941-stop-filter-xregs-no-appl-on-libsunec/webrev.01 /Magnus
