Re: RFR: 8265783: Create a separate library for x86 Intel SVML assembly intrinsics [v9]
On Wed, 19 May 2021 03:37:11 GMT, Sandhya Viswanathan wrote: >> This PR contains Short Vector Math Library support related changes for >> [JEP-414 Vector API (Second Incubator)](https://openjdk.java.net/jeps/414), >> in preparation for when targeted. >> >> Intel Short Vector Math Library (SVML) based intrinsics in native x86 >> assembly provide optimized implementation for Vector API transcendental and >> trigonometric methods. >> These methods are built into a separate library instead of being part of >> libjvm.so or jvm.dll. >> >> The following changes are made: >>The source for these methods is placed in the jdk.incubator.vector module >> under src/jdk.incubator.vector/linux/native/libsvml and >> src/jdk.incubator.vector/windows/native/libsvml. >>The assembly source files are named as “*.S” and include files are named >> as “*.S.inc”. >>The corresponding build script is placed at >> make/modules/jdk.incubator.vector/Lib.gmk. >>Changes are made to build system to support dependency tracking for >> assembly files with includes. >>The built native libraries (libsvml.so/svml.dll) are placed in bin >> directory of JDK on Windows and lib directory of JDK on Linux. >>The C2 JIT uses the dll_load and dll_lookup to get the addresses of >> optimized methods from this library. >> >> Build system changes and module library build scripts are contributed by >> Magnus (magnus.ihse.bur...@oracle.com). >> >> Looking forward to your review and feedback. >> >> Performance: >> Micro benchmark Base Optimized Unit Gain(Optimized/Base) >> Double128Vector.ACOS 45.91 87.34 ops/ms 1.90 >> Double128Vector.ASIN 45.06 92.36 ops/ms 2.05 >> Double128Vector.ATAN 19.92 118.36 ops/ms 5.94 >> Double128Vector.ATAN2 15.24 88.17 ops/ms 5.79 >> Double128Vector.CBRT 45.77 208.36 ops/ms 4.55 >> Double128Vector.COS 49.94 245.89 ops/ms 4.92 >> Double128Vector.COSH 26.91 126.00 ops/ms 4.68 >> Double128Vector.EXP 71.64 379.65 ops/ms 5.30 >> Double128Vector.EXPM1 35.95 150.37 ops/ms 4.18 >> Double128Vector.HYPOT 50.67 174.10 ops/ms 3.44 >> Double128Vector.LOG 61.95 279.84 ops/ms 4.52 >> Double128Vector.LOG10 59.34 239.05 ops/ms 4.03 >> Double128Vector.LOG1P 18.56 200.32 ops/ms 10.79 >> Double128Vector.SIN 49.36 240.79 ops/ms 4.88 >> Double128Vector.SINH 26.59 103.75 ops/ms 3.90 >> Double128Vector.TAN 41.05 152.39 ops/ms 3.71 >> Double128Vector.TANH 45.29 169.53 ops/ms 3.74 >> Double256Vector.ACOS 54.21 106.39 ops/ms 1.96 >> Double256Vector.ASIN 53.60 107.99 ops/ms 2.01 >> Double256Vector.ATAN 21.53 189.11 ops/ms 8.78 >> Double256Vector.ATAN2 16.67 140.76 ops/ms 8.44 >> Double256Vector.CBRT 56.45 397.13 ops/ms 7.04 >> Double256Vector.COS 58.26 389.77 ops/ms 6.69 >> Double256Vector.COSH 29.44 151.11 ops/ms 5.13 >> Double256Vector.EXP 86.67 564.68 ops/ms 6.52 >> Double256Vector.EXPM1 41.96 201.28 ops/ms 4.80 >> Double256Vector.HYPOT 66.18 305.74 ops/ms 4.62 >> Double256Vector.LOG 71.52 394.90 ops/ms 5.52 >> Double256Vector.LOG10 65.43 362.32 ops/ms 5.54 >> Double256Vector.LOG1P 19.99 300.88 ops/ms 15.05 >> Double256Vector.SIN 57.06 380.98 ops/ms 6.68 >> Double256Vector.SINH 29.40 117.37 ops/ms 3.99 >> Double256Vector.TAN 44.90 279.90 ops/ms 6.23 >> Double256Vector.TANH 54.08 274.71 ops/ms 5.08 >> Double512Vector.ACOS 55.65 687.54 ops/ms 12.35 >> Double512Vector.ASIN 57.31 777.72 ops/ms 13.57 >> Double512Vector.ATAN 21.42 729.21 ops/ms 34.04 >> Double512Vector.ATAN2 16.37 414.33 ops/ms 25.32 >> Double512Vector.CBRT 56.78 834.38 ops/ms 14.69 >> Double512Vector.COS 59.88 837.04 ops/ms 13.98 >> Double512Vector.COSH 30.34 172.76 ops/ms 5.70 >> Double512Vector.EXP 99.66 1608.12 ops/ms 16.14 >> Double512Vector.EXPM1 43.39 318.61 ops/ms 7.34 >> Double512Vector.HYPOT 73.87 1502.72 ops/ms 20.34 >> Double512Vector.LOG 74.84 996.00 ops/ms 13.31 >> Double512Vector.LOG10 71.12 1046.52 ops/ms 14.72 >> Double512Vector.LOG1P 19.75 776.87 ops/ms 39.34 >> Double512Vector.POW 37.42 384.13 ops/ms 10.26 >> Double512Vector.SIN 59.74 728.45 ops/ms 12.19 >> Double512Vector.SINH 29.47 143.38 ops/ms 4.87 >> Double512Vector.TAN 46.20 587.21 ops/ms 12.71 >> Double512Vector.TANH 57.36 495.42 ops/ms 8.64 >> Double64Vector.ACOS 24.04 73.67 ops/ms 3.06 >> Double64Vector.ASIN 23.78 75.11 ops/ms 3.16 >> Double64Vector.ATAN 14.14 62.81 ops/ms 4.44 >> Double64Vector.ATAN2 10.38 44.43 ops/ms 4.28 >> Double64Vector.CBRT 16.47 107.50 ops/ms 6.53 >> Double64Vector.COS 23.42 152.01 ops/ms 6.49 >> Double64Vector.COSH 17.34 113.34 ops/ms 6.54 >> Double64Vector.EXP 27.08 203.53 ops/ms 7.52 >> Double64Vector.EXPM1 18.77 96.73 ops/ms 5.15 >> Double64Vector.HYPOT 18.54 103.62 ops/ms 5.59 >> Double64Vector.LOG 26.75 142.63 ops/ms 5.33 >> Double64Vector.LOG10 25.85 139.71 ops/ms 5.40 >> Double64Vector.LOG1P 13.26 97.94 ops/ms 7.38 >> Double64Vector.SIN 23.28 146.91 ops/ms 6.31 >> Double64Vector.SINH 17.62 88.59 ops/ms 5.03 >> Double64Vector.TAN 21.00 86.43 ops/ms 4.12 >> Double64Vector.TANH 23.75 111.35 ops/ms 4.69 >> Float128Vector.ACOS 57.52 110.65
Re: RFR: 8264188: Improve handling of assembly files in the JDK [v2]
On Mon, 29 Mar 2021 10:48:55 GMT, Magnus Ihse Bursie wrote:
>> We have a handful of assembly files in the JDK. They have long been left
>> aside, with a "if it ain't broken, don't fix it" attitude.
>>
>> In the current panama-vector, there is a lot more assembly files incoming,
>> including for the Windows platforrm, which has not existed for a long time
>> in the JDK.
>>
>> It is time to give assembly files some more love and care. This patch cleans
>> up the handling in the build system, and it unifies between .s and .S files.
>>
>> For historical reasons, .s has been the suffix used in the posix world to
>> signify assembly output as generated by a compiler, and .S to signify
>> "hand-written" precious assembly. One effect of this is that gcc and clang
>> will run the preprocessor on files named .S but not on files named .s.
>>
>> All our files are "hand-written" in this sense, and should have the .S
>> suffix. But not all had. On mac, it was even worse, where the files were
>> named .s but the option `-x assembler-with-cpp` was used to force clang to
>> treat them as .S files instead... This change however made the preprocesser
>> try to parse comments of the form
>>
>> # if (a) {
>>
>> as preprocessor directives, and balk at them. In one of the files, I had to
>> wrap this in preprocessor comments (`/* ... */`).
>>
>> We also had inconsistent handling on dependencies. For preprocessed assembly
>> files, it really makes sense to have dependency tracking, exactly as for
>> C/C++ files. Now the dependency tracking in NativeCompilation is simplified,
>> and applies to all files. (The sole exception is Windows assembly, since
>> masm is unable to output dependency information, even though it is able to
>> include files :-().
>>
>> This patch has been partly written by Sandhya Viswanathan
>> for the panama-vector repo.
>
> Magnus Ihse Bursie has updated the pull request incrementally with one
> additional commit since the last revision:
>
> Use OPENJDK_BUILD_CPU_BITS instead
Looks good!
Thanks a lot for taking care of it.
-
Marked as reviewed by vlivanov (Reviewer).
PR: https://git.openjdk.java.net/jdk/pull/3198
Re: RFR: 8256414: add optimized build to submit workflow
There is a long-standing bug with the intent to remove optimized builds (https://bugs.openjdk.java.net/browse/JDK-8183287). Given that it does not seem that popular, I wonder if it really is necessary to burden the submit workflow (and tier1 testing, as requested in https://bugs.openjdk.java.net/browse/JDK-8256430) with this. At the very least, I'd like to get some input from more Hotspot developers to hear if they think it is a worthy cause to spend our resources at. Otherwise, I believe a better way forward is to follow through on JDK-8183287, viz. to split up optimized builds into the two extra components it actually provides: enable diagnostic code in normal release builds (https://bugs.openjdk.java.net/browse/JDK-8183288) and enable tracing with INCLUDE_PRINT (https://bugs.openjdk.java.net/browse/JDK-8202283). I find !PRODUCT vs ASSERT distinction confusing, but irrespective of the way the relevant code is guarded (!PRODUCT or INCLUDE_PRINT), it has to be built regularly to avoid the rot. So, once the bugs you mentioned are addressed, optimized build can be replaced with release build + tracing configuration. Regarding the most appropriate tier to put it, I don't think it has to be part of tier1. IMO later tiers are fine as well. But having it in tier1 doesn't look like a significant waste of resources. I don't think there's a notion of tiers in submit workflow, so I'm strongly in favor of having optimized configuration built there. Best regards, Vladimir Ivanov On 2020-11-16 19:33, Igor Ignatyev wrote: Hi all, Could you please review this small and trivial patch which adds `linux-x64-optimized` build to submit workflow so breakages of this build flavor would be easier to spot? Thanks, -- Igor - Commit messages: - add linux-x64-optimized build Changes: https://git.openjdk.java.net/jdk/pull/1233/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk=1233=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8256414 Stats: 4 lines in 1 file changed: 4 ins; 0 del; 0 mod Patch: https://git.openjdk.java.net/jdk/pull/1233.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1233/head:pull/1233 PR: https://git.openjdk.java.net/jdk/pull/1233
Re: RFR: 8256430: add linux-x64-optimized to tier1
On Tue, 17 Nov 2020 00:31:24 GMT, Igor Ignatyev wrote: > Hi all, > > > [8256414](https://bugs.openjdk.java.net/browse/JDK-8256414) / #1233 added > similar profile to submit workflow, this patch defines `linux-x64-optimized` > profile in jib-profile so it can be used by mach5 and added to tier1? > > Thanks > -- Igor > > cc-ing @dcubed-ojdk Looks good. - Marked as reviewed by vlivanov (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/1244
Re: RFR: 8256414: add optimized build to submit workflow
On Mon, 16 Nov 2020 18:26:18 GMT, Igor Ignatyev wrote: > Hi all, > > Could you please review this small and trivial patch which adds > `linux-x64-optimized` build to submit workflow so breakages of this build > flavor would be easier to spot? > > Thanks, > -- Igor Thanks a lot, Igor! Looks good. - Marked as reviewed by vlivanov (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/1233
Re: RFR: 8255616: Disable AOT and Graal in Oracle OpenJDK
On Fri, 30 Oct 2020 17:40:51 GMT, Vladimir Kozlov wrote: > We shipped Ahead-of-Time compilation (the jaotc tool) in JDK 9, as an > experimental feature. We shipped Graal as an experimental JIT compiler in JDK > 10. We haven't seen much use of these features, and the effort required to > support and enhance them is significant. We therefore intend to disable these > features in Oracle builds as of JDK 16. > > We'll leave the sources for these features in the repository, in case any one > else is interested in building them. But we will not update or test them. > > We'll continue to build and ship JVMCI as an experimental feature in Oracle > builds. > > Tested changes in all tiers. > > I verified that with these changes I still able to build Graal in open repo > and run graalunit testing: > > `open$ bash test/hotspot/jtreg/compiler/graalunit/downloadLibs.sh > /mydir/graalunit_lib/` > `open$ bash configure --with-debug-level=fastdebug > --with-graalunit-lib=/mydir/graalunit_lib/ --with-jtreg=/mydir/jtreg` > `open$ make jdk-image` > `open$ make test-image` > `open$ make run-test TEST=compiler/graalunit/HotspotTest.java` Looks good. - Marked as reviewed by vlivanov (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/960
Re: [13] RFR (S): 8217404: --with-jvm-features doesn't work when multiple features are explicitly disabled
Vladimir, if you're okay with it I'd like to propose this as a patch to
the problem instead:
http://cr.openjdk.java.net/~ihse/JDK-8217404-fix-multiple-disabled-jvm-features/webrev.01
Looks good! I verified that it fixes the bug.
Best regards,
Vladimir Ivanov
On Jan 18, 2019, at 3:33 PM, Vladimir Ivanov
wrote:
http://cr.openjdk.java.net/~vlivanov/8217404/webrev.00/
https://bugs.openjdk.java.net/browse/JDK-8217404
--with-jvm-features doesn't work properly when multiple features are
explicitly disabled:
$ bash configure --with-jvm-features="-aot -jvmci -graal"
...
checking if jvmci module jdk.internal.vm.ci should be built... yes
checking if graal module jdk.internal.vm.compiler should be built...
yes
checking if aot should be enabled... yes
...
The problem in the following code:
DISABLE_AOT=`$ECHO $DISABLED_JVM_FEATURES | $GREP aot`
if test "x$DISABLE_AOT" = "xaot"; then
ENABLE_AOT="false"
fi
Since DISABLED_JVM_FEATURES ("aot jvmci graal") contains the list of
explicitly disabled features, grep over it returns the whole list
when there's a match. The subsequent check fails because there's no
exact match, though DISABLE_AOT contains "aot" .
Proposed fix is to check there's no match instead.
After the fix it works as expected:
$ bash configure --with-jvm-features="-aot -jvmci -graal"
...
checking if jvmci module jdk.internal.vm.ci should be built... no,
forced
checking if graal module jdk.internal.vm.compiler should be built...
no, forced
checking if aot should be enabled... no, forced
...
(The fix doesn't address the case when one feature has a name which
is a proper substring of another feature, but there are no such
cases at the moment.)
Best regards,
Vladimir Ivanov
Re: [13] RFR (S): 8217404: --with-jvm-features doesn't work when multiple features are explicitly disabled
Updated webrev:
http://cr.openjdk.java.net/~vlivanov/8217404/webrev.01
Verified that it works as expected on Linux, Windows, MacOS, and Solaris.
Best regards,
Vladimir Ivanov
On 18/01/2019 16:39, Vladimir Ivanov wrote:
Thanks, Igor.
overall your fix looks reasonable, but w/ it we can get
unintentionally disabled features (b/c grep doesn't do full word
match). although this problem wasn't really introduced by your fix, I
think it's be better to fix it as a part of your patch. I see two
possible solutions:
I was aware of such drawback, but decided to leave it as is, since it
doesn't affect existing features.
- add "-w" to grep, but I am not sure if "-w" is supported by all
grep implementations
- use $XARGS instead of $ECHO when we get DISABLE_X. in this case
you will need to revert your changes in 'if test ...' lines
I'm in favor of using "-w" and I see different grep flags being used
already, but would like somebody from Build team confirm they are OK
with such solution.
Best regards,
Vladimir Ivanov
On Jan 18, 2019, at 3:33 PM, Vladimir Ivanov
wrote:
http://cr.openjdk.java.net/~vlivanov/8217404/webrev.00/
https://bugs.openjdk.java.net/browse/JDK-8217404
--with-jvm-features doesn't work properly when multiple features are
explicitly disabled:
$ bash configure --with-jvm-features="-aot -jvmci -graal"
...
checking if jvmci module jdk.internal.vm.ci should be built... yes
checking if graal module jdk.internal.vm.compiler should be built... yes
checking if aot should be enabled... yes
...
The problem in the following code:
DISABLE_AOT=`$ECHO $DISABLED_JVM_FEATURES | $GREP aot`
if test "x$DISABLE_AOT" = "xaot"; then
ENABLE_AOT="false"
fi
Since DISABLED_JVM_FEATURES ("aot jvmci graal") contains the list of
explicitly disabled features, grep over it returns the whole list
when there's a match. The subsequent check fails because there's no
exact match, though DISABLE_AOT contains "aot" .
Proposed fix is to check there's no match instead.
After the fix it works as expected:
$ bash configure --with-jvm-features="-aot -jvmci -graal"
...
checking if jvmci module jdk.internal.vm.ci should be built... no,
forced
checking if graal module jdk.internal.vm.compiler should be built...
no, forced
checking if aot should be enabled... no, forced
...
(The fix doesn't address the case when one feature has a name which
is a proper substring of another feature, but there are no such cases
at the moment.)
Best regards,
Vladimir Ivanov
Re: [13] RFR (S): 8217404: --with-jvm-features doesn't work when multiple features are explicitly disabled
Thanks, Igor.
overall your fix looks reasonable, but w/ it we can get unintentionally
disabled features (b/c grep doesn't do full word match). although this problem
wasn't really introduced by your fix, I think it's be better to fix it as a
part of your patch. I see two possible solutions:
I was aware of such drawback, but decided to leave it as is, since it
doesn't affect existing features.
- add "-w" to grep, but I am not sure if "-w" is supported by all grep
implementations
- use $XARGS instead of $ECHO when we get DISABLE_X. in this case you will
need to revert your changes in 'if test ...' lines
I'm in favor of using "-w" and I see different grep flags being used
already, but would like somebody from Build team confirm they are OK
with such solution.
Best regards,
Vladimir Ivanov
On Jan 18, 2019, at 3:33 PM, Vladimir Ivanov
wrote:
http://cr.openjdk.java.net/~vlivanov/8217404/webrev.00/
https://bugs.openjdk.java.net/browse/JDK-8217404
--with-jvm-features doesn't work properly when multiple features are explicitly
disabled:
$ bash configure --with-jvm-features="-aot -jvmci -graal"
...
checking if jvmci module jdk.internal.vm.ci should be built... yes
checking if graal module jdk.internal.vm.compiler should be built... yes
checking if aot should be enabled... yes
...
The problem in the following code:
DISABLE_AOT=`$ECHO $DISABLED_JVM_FEATURES | $GREP aot`
if test "x$DISABLE_AOT" = "xaot"; then
ENABLE_AOT="false"
fi
Since DISABLED_JVM_FEATURES ("aot jvmci graal") contains the list of explicitly disabled
features, grep over it returns the whole list when there's a match. The subsequent check fails
because there's no exact match, though DISABLE_AOT contains "aot" .
Proposed fix is to check there's no match instead.
After the fix it works as expected:
$ bash configure --with-jvm-features="-aot -jvmci -graal"
...
checking if jvmci module jdk.internal.vm.ci should be built... no, forced
checking if graal module jdk.internal.vm.compiler should be built... no, forced
checking if aot should be enabled... no, forced
...
(The fix doesn't address the case when one feature has a name which is a proper
substring of another feature, but there are no such cases at the moment.)
Best regards,
Vladimir Ivanov
Re: [13] RFR (S): 8217404: --with-jvm-features doesn't work when multiple features are explicitly disabled
Thanks, Vladimir.
I usually used --with-jvm-features=-aot,-jvmci,-graal
Did not work in this case too?
I didn't know it supports comma-separated list, but it doesn't work as
well:
$ bash configure --with-jvm-features="-aot,-jvmci,-graal"
checking if jvmci module jdk.internal.vm.ci should be built... yes
checking if graal module jdk.internal.vm.compiler should be built... yes
checking if aot should be enabled... yes
Best regards,
Vladimir Ivanov
On 1/18/19 3:33 PM, Vladimir Ivanov wrote:
http://cr.openjdk.java.net/~vlivanov/8217404/webrev.00/
https://bugs.openjdk.java.net/browse/JDK-8217404
--with-jvm-features doesn't work properly when multiple features are
explicitly disabled:
$ bash configure --with-jvm-features="-aot -jvmci -graal"
...
checking if jvmci module jdk.internal.vm.ci should be built... yes
checking if graal module jdk.internal.vm.compiler should be built... yes
checking if aot should be enabled... yes
...
The problem in the following code:
DISABLE_AOT=`$ECHO $DISABLED_JVM_FEATURES | $GREP aot`
if test "x$DISABLE_AOT" = "xaot"; then
ENABLE_AOT="false"
fi
Since DISABLED_JVM_FEATURES ("aot jvmci graal") contains the list of
explicitly disabled features, grep over it returns the whole list when
there's a match. The subsequent check fails because there's no exact
match, though DISABLE_AOT contains "aot" .
Proposed fix is to check there's no match instead.
After the fix it works as expected:
$ bash configure --with-jvm-features="-aot -jvmci -graal"
...
checking if jvmci module jdk.internal.vm.ci should be built... no, forced
checking if graal module jdk.internal.vm.compiler should be built...
no, forced
checking if aot should be enabled... no, forced
...
(The fix doesn't address the case when one feature has a name which is
a proper substring of another feature, but there are no such cases at
the moment.)
Best regards,
Vladimir Ivanov
[13] RFR (S): 8217404: --with-jvm-features doesn't work when multiple features are explicitly disabled
http://cr.openjdk.java.net/~vlivanov/8217404/webrev.00/
https://bugs.openjdk.java.net/browse/JDK-8217404
--with-jvm-features doesn't work properly when multiple features are
explicitly disabled:
$ bash configure --with-jvm-features="-aot -jvmci -graal"
...
checking if jvmci module jdk.internal.vm.ci should be built... yes
checking if graal module jdk.internal.vm.compiler should be built... yes
checking if aot should be enabled... yes
...
The problem in the following code:
DISABLE_AOT=`$ECHO $DISABLED_JVM_FEATURES | $GREP aot`
if test "x$DISABLE_AOT" = "xaot"; then
ENABLE_AOT="false"
fi
Since DISABLED_JVM_FEATURES ("aot jvmci graal") contains the list of
explicitly disabled features, grep over it returns the whole list when
there's a match. The subsequent check fails because there's no exact
match, though DISABLE_AOT contains "aot" .
Proposed fix is to check there's no match instead.
After the fix it works as expected:
$ bash configure --with-jvm-features="-aot -jvmci -graal"
...
checking if jvmci module jdk.internal.vm.ci should be built... no, forced
checking if graal module jdk.internal.vm.compiler should be built... no,
forced
checking if aot should be enabled... no, forced
...
(The fix doesn't address the case when one feature has a name which is a
proper substring of another feature, but there are no such cases at the
moment.)
Best regards,
Vladimir Ivanov
Re: RFR(M/L) : 8209611 : use C++ compiler for hotspot tests
http://cr.openjdk.java.net/~iignatyev//8209611/webrev.02/index.html Reviewed. Best regards, Vladimir Ivanov On Aug 20, 2018, at 11:07 PM, Igor Ignatyev wrote: It has been discussed (not widely enough and I accept that) in 8209547 and the related email thread b/w JC(cc'ed) and myself. as I said, I might went a way too far, so I'll revert changes in the non-vmTestbase tests and made appropriate changes in makefiles. what do you think? I think I need to see what you mean exactly :) sure, it will take some time for me to do that, hopefully will upload new webrevs tomorrow morning PT. but the basic idea is to leave files in test/hotspot/jtreg/compiler, runtime, gc, native_sanity, serviceability, testlibrary as .c files, exactly as they were before, and restore corresponding filenames in make/test/JtregNativeHotspot.gmk.
Re: How to disable JVM features?
Thanks, Magnus! That works for me. Best regards, Vladimir Ivanov On 12/1/17 11:33 PM, Magnus Ihse Bursie wrote: You cannot disable features. However, you can create your own complete set of features. Use --with-jvm-variants=custom. The custom variant starts out with a comletely empty set of features. Then use --with-jvm-features=compiler1,minimal,... whatever you want. Please be adviced that not all combinations is possible to build, or makes sense. Or even if it's possible to build, it might not work. The closer you stay to a predefined combination, the more likely it is to work. /Magnus On 2017-11-30 19:35, Vladimir Ivanov wrote: Hi, I'm curious is there a way to disable JVM features from the default list. Configure mentions --with-jvm-features [1], but it doesn't allow to remove features which are enabled by default (tried to override the list, but it didn't work). Thanks! Best regards, Vladimir Ivanov [1] --with-jvm-features additional JVM features to enable (separated by comma), use '--help' to show possible values [none] ... The following JVM features are available as arguments to --with-jvm-features. Which are valid to use depends on the target platform. compiler1 compiler2 zero minimal dtrace jvmti jvmci graal vm-structs jni-check services management all-gcs nmt cds static-build link-time-opt aot closed-src commercial-features trace
How to disable JVM features?
Hi, I'm curious is there a way to disable JVM features from the default list. Configure mentions --with-jvm-features [1], but it doesn't allow to remove features which are enabled by default (tried to override the list, but it didn't work). Thanks! Best regards, Vladimir Ivanov [1] --with-jvm-features additional JVM features to enable (separated by comma), use '--help' to show possible values [none] ... The following JVM features are available as arguments to --with-jvm-features. Which are valid to use depends on the target platform. compiler1 compiler2 zero minimal dtrace jvmti jvmci graal vm-structs jni-check services management all-gcs nmt cds static-build link-time-opt aot closed-src commercial-features trace
Re: RFR(XS): 8185567: fix hsdis cpu to architecture mapping on various Linux platforms
Looks good! Best regards, Vladimir Ivanov On 8/1/17 5:32 AM, David Buck wrote: Hi! It was suggested that I also loop in build-dev to the review of this proposed change. Cheers, -Buck On 2017/07/31 22:06, David Buck wrote: Hi! Would you please review this small set of very simple build fixes to hsdis? bug report: https://bugs.openjdk.java.net/browse/JDK-8185567 proposed fix: http://cr.openjdk.java.net/~dbuck/8185567.0/ With these changes, hsdis should now correctly build out of the box (no manual editing of files needed) on Linux with any of the following return values of "uname -m": i386 i686 amd64 x86_64 *arm* aarch64 I made it a point to *not* break anything that previously worked. So, for example, aarch64 environments will still compile for aarch64 even when the build target is "all" and not "all64". While forcing it to try and build a 32-bit binary would be more consistent with what happens with "make all" on linux-amd64 or solaris-sparcv9, I decided to leave things as they are in case any aarch64 users depend on the current behavior. Similarly, an attempt to run "make all" on linux-sparcv9 will continue to try and build against whatever the return value of "uname -m" was. Of course running "make all64" now does the right thing and targets "sparcv9". Cheers, -Buck
Re: RFR (L) JEP 280: Indify String Concatenation (integration)
JDK changes looks good!
Best regards,
Vladimir Ivanov
On 1/27/16 4:55 PM, Aleksey Shipilev wrote:
Hi again,
This is a formal pre-integration review thread for JEP 280 ("Indify
String Concatenation") integration:
http://openjdk.java.net/jeps/280
The JEP is Targeted, the CCC is approved, the code reviews and
pre-integration checks are clean.
Code changes are happening simultaneously in four components:
a) (M) javac changes that emit indy:
http://cr.openjdk.java.net/~shade/8085796/webrev.langtools.05/
b) (L) JDK changes with StringConcatFactory and friends, plus fixing
the regression tests that do not expect additional indys:
http://cr.openjdk.java.net/~shade/8085796/webrev.jdk.08/
c) (XS) Build changes that force emitting the "legacy" inline
StringBuilder concat in a few cases (e.g. when pre-JDK 9 bytecode is
expected):
http://cr.openjdk.java.net/~shade/8085796/webrev.root.00/
d) (XS) HotSpot changes that fix a GC regression test that now
allocates some metaspace from within the test methods having a string
concatenation:
http://cr.openjdk.java.net/~shade/8085796/webrev.hs.00/
These changes were already reviewed by multiple people, and so I would
like to keep the comments only for serious breaking issues at this
point. (Note that this thread cross-posts over several mailing lists:
bike-shedding discussion would get multiplied a lot!)
Formal acknowledgements from Reviewers would be appreciated. Pending no
show-stopper comments, I'd like to push this through jdk9/dev in 24 hours.
Thanks,
-Aleksey
Re: RFR: JDK-8141051: Build test libs -source/-target 9
Looks good. Thanks for fixing it! Best regards, Vladimir Ivanov On 10/30/15 3:51 PM, Erik Joelsson wrote: Hello, Here is a new patch for this where I did some more cleanup. Webrev: http://cr.openjdk.java.net/~erikj/8141051/webrev.01/ Bug: https://bugs.openjdk.java.net/browse/JDK-8141051 /Erik On 2015-10-29 15:48, Erik Joelsson wrote: Hello, On 2015-10-29 14:43, Vladimir Ivanov wrote: Hi, Quick question: I have to use Java9 API in sun.misc.WhiteBox, but right now it is built using BOOT_JDK. Does the following change [1] look good? The changes look ok, but may impact build times as the building of tests will have to wait for a lot more of the product to finish before starting. Of course, if you need it, you need it. The following dependency seems too conservative (depends on hotspot which is not necessary): build-test-lib: $(JAVA_TARGETS) but I haven't found how to enumerate only JDK modules: The problem is that the java code for jdk.hotspot.agent is built in the monolithic hotspot target. That in turn makes jdk.jdi-gensrc depend on hotspot for now. If we could disentangle that java compilation from hotspot, we would be able to build all the jdk java source without building hotspot. /Erik Thanks! Best regards, Vladimir Ivanov [1] diff --git a/make/Main.gmk b/make/Main.gmk --- a/make/Main.gmk +++ b/make/Main.gmk @@ -452,6 +452,8 @@ test-make: clean-test-make + build-test-lib: $(JAVA_TARGETS) + build-test-hotspot-jtreg-native: buildtools-jdk build-test-jdk-jtreg-native: buildtools-jdk diff --git a/make/test/BuildTestLib.gmk b/make/test/BuildTestLib.gmk --- a/make/test/BuildTestLib.gmk +++ b/make/test/BuildTestLib.gmk @@ -35,14 +35,8 @@ TEST_LIB_SOURCE_DIR := $(TOPDIR)/test/lib TEST_LIB_SUPPORT := $(SUPPORT_OUTPUTDIR)/test/lib -# Unfortunately, test-lib.jar does not compile properly without warnings. -$(eval $(call SetupJavaCompiler, BOOT_JAVAC_NOWARNINGS, \ -JAVAC := $(JAVAC), \ -FLAGS := -XDignore.symbol.file=true -g, \ -)) - $(eval $(call SetupJavaCompilation, BUILD_WB_JAR, \ -SETUP := BOOT_JAVAC, \ +SETUP := GENERATE_USINGJDKBYTECODE, \ SRC := $(TEST_LIB_SOURCE_DIR)/sun, \ BIN := $(TEST_LIB_SUPPORT), \ JAR := $(TEST_LIB_SUPPORT)/wb.jar, \ @@ -52,7 +46,7 @@ # test-lib.jar will contain only hprof classes until JDK-8081381 is resolved $(eval $(call SetupJavaCompilation, BUILD_TEST_LIB_JAR, \ -SETUP := BOOT_JAVAC_NOWARNINGS, \ +SETUP := GENERATE_USINGJDKBYTECODE, \ SRC := $(TEST_LIB_SOURCE_DIR)/share/classes/jdk/test/lib/hprof, \ BIN := $(TEST_LIB_SUPPORT), \ JAR := $(TEST_LIB_SUPPORT)/test-lib.jar, \
JDK9: Build wb.jar which depends on JDK9 API
Hi, Quick question: I have to use Java9 API in sun.misc.WhiteBox, but right now it is built using BOOT_JDK. Does the following change [1] look good? The following dependency seems too conservative (depends on hotspot which is not necessary): build-test-lib: $(JAVA_TARGETS) but I haven't found how to enumerate only JDK modules: Thanks! Best regards, Vladimir Ivanov [1] diff --git a/make/Main.gmk b/make/Main.gmk --- a/make/Main.gmk +++ b/make/Main.gmk @@ -452,6 +452,8 @@ test-make: clean-test-make + build-test-lib: $(JAVA_TARGETS) + build-test-hotspot-jtreg-native: buildtools-jdk build-test-jdk-jtreg-native: buildtools-jdk diff --git a/make/test/BuildTestLib.gmk b/make/test/BuildTestLib.gmk --- a/make/test/BuildTestLib.gmk +++ b/make/test/BuildTestLib.gmk @@ -35,14 +35,8 @@ TEST_LIB_SOURCE_DIR := $(TOPDIR)/test/lib TEST_LIB_SUPPORT := $(SUPPORT_OUTPUTDIR)/test/lib -# Unfortunately, test-lib.jar does not compile properly without warnings. -$(eval $(call SetupJavaCompiler, BOOT_JAVAC_NOWARNINGS, \ -JAVAC := $(JAVAC), \ -FLAGS := -XDignore.symbol.file=true -g, \ -)) - $(eval $(call SetupJavaCompilation, BUILD_WB_JAR, \ -SETUP := BOOT_JAVAC, \ +SETUP := GENERATE_USINGJDKBYTECODE, \ SRC := $(TEST_LIB_SOURCE_DIR)/sun, \ BIN := $(TEST_LIB_SUPPORT), \ JAR := $(TEST_LIB_SUPPORT)/wb.jar, \ @@ -52,7 +46,7 @@ # test-lib.jar will contain only hprof classes until JDK-8081381 is resolved $(eval $(call SetupJavaCompilation, BUILD_TEST_LIB_JAR, \ -SETUP := BOOT_JAVAC_NOWARNINGS, \ +SETUP := GENERATE_USINGJDKBYTECODE, \ SRC := $(TEST_LIB_SOURCE_DIR)/share/classes/jdk/test/lib/hprof, \ BIN := $(TEST_LIB_SUPPORT), \ JAR := $(TEST_LIB_SUPPORT)/test-lib.jar, \
