Re: RFR: 8333477: Delete extra empty spaces in Makefiles [v2]

2024-06-07 Thread Erik Joelsson
On Fri, 7 Jun 2024 12:37:48 GMT, Julian Waters wrote: >> SendaoYan has updated the pull request incrementally with one additional >> commit since the last revision: >> >> delete extra empty trailing blank line in >> test/jdk/java/rmi/reliability/benchmark/bench/Makefile > >

Re: RFR: 8333477: Delete extra empty spaces in Makefiles [v2]

2024-06-07 Thread Erik Joelsson
On Fri, 7 Jun 2024 07:29:39 GMT, SendaoYan wrote: >> Hi all, >> This PR several extra empty spaces and extra empty lines in several >> Makefiles. It's trivial fix, no risk. >> >> Thanks. > > SendaoYan has updated the pull request incrementally with one additional > commit since the last

Re: RFR: 8311302: Allow for jlinking a custom runtime without packaged modules being present [v31]

2024-06-05 Thread Erik Joelsson
On Wed, 5 Jun 2024 17:31:44 GMT, Severin Gehwolf wrote: >> Please review this patch which adds a jlink mode to the JDK which doesn't >> need the packaged modules being present. A.k.a run-time image based jlink. >> Fundamentally this patch adds an option to use `jlink` even though your JDK >>

Re: RFR: 8333477: Delete extra empty spaces in Makefiles

2024-06-04 Thread Erik Joelsson
On Tue, 4 Jun 2024 07:47:46 GMT, SendaoYan wrote: > Hi all, > This PR several extra empty spaces and extra empty lines in several > Makefiles. It's trivial fix, no risk. > > Thanks. Marked as reviewed by erikj (Reviewer). - PR Review:

Re: RFR: 8333301: Remove static builds using --enable-static-build

2024-05-31 Thread Erik Joelsson
On Thu, 30 May 2024 19:14:43 GMT, Magnus Ihse Bursie wrote: > The original way of building static libraries in the JDK was to use the > configure argument --enable-static-build, which set the value of the make > variable STATIC_BUILD. (Note that this is not the same as the source code >

Re: RFR: 8332885: Clarify failure_handler self-tests

2024-05-24 Thread Erik Joelsson
On Fri, 24 May 2024 12:16:25 GMT, Ludvig Janiuk wrote: > Adding commetns to clarify that the failure_handler selftests are intended to > be run manually. Ideally this would include a more thorough description of > the exepcted outputs, but this is what I have time to add right now.

Re: RFR: 8330542: Add jaxp-strict.properties in preparation for a secure by default configuration [v9]

2024-05-17 Thread Erik Joelsson
On Fri, 17 May 2024 21:57:00 GMT, Joe Wang wrote: >> Add two sample configuration files: >> >> jaxp-strict.properties: used to set strict configuration, stricter than >> jaxp.properties in previous versions such as JDK 22 >> >>> jaxp-compat.properties: used to regain compatibility from

Re: RFR: 8330542: Add jaxp-strict.properties in preparation for a secure by default configuration [v8]

2024-05-17 Thread Erik Joelsson
On Fri, 17 May 2024 05:51:31 GMT, Alan Bateman wrote: >> Joe Wang has updated the pull request incrementally with one additional >> commit since the last revision: >> >> remove jaxp-compat.properties from the list > > make/modules/java.xml/Copy.gmk line 37: > >> 35:

Re: RFR: 8330542: Add jaxp-strict.properties in preparation for a secure by default configuration [v8]

2024-05-17 Thread Erik Joelsson
On Thu, 16 May 2024 22:20:39 GMT, Joe Wang wrote: >> Add two sample configuration files: >> >> jaxp-strict.properties: used to set strict configuration, stricter than >> jaxp.properties in previous versions such as JDK 22 >> >>> jaxp-compat.properties: used to regain compatibility from

Re: RFR: 8331671: Implement JEP 472: Prepare to Restrict the Use of JNI [v3]

2024-05-13 Thread Erik Joelsson
On Mon, 13 May 2024 11:47:38 GMT, Maurizio Cimadamore wrote: >> This PR implements [JEP 472](https://openjdk.org/jeps/472), by restricting >> the use of JNI in the following ways: >> >> * `System::load` and `System::loadLibrary` are now restricted methods >> * `Runtime::load` and

Re: RFR: 8311302: Allow for jlinking a custom runtime without packaged modules being present [v24]

2024-04-04 Thread Erik Joelsson
On Thu, 4 Apr 2024 15:24:53 GMT, Severin Gehwolf wrote: >> make/CompileToolsJdk.gmk line 50: >> >>> 48: EXCLUDES := \ >>> 49: build/tools/classlist \ >>> 50: build/tools/runtimeimagelinkdeltaproducer \ >> >> This directory name is comically long. I guess that's not really a

Re: RFR: 8311302: Allow for jlinking a custom runtime without packaged modules being present [v24]

2024-04-04 Thread Erik Joelsson
On Thu, 4 Apr 2024 11:12:43 GMT, Severin Gehwolf wrote: >> Please review this patch which adds a jlink mode to the JDK which doesn't >> need the packaged modules being present. A.k.a run-time image based jlink. >> Fundamentally this patch adds an option to use `jlink` even though your JDK >>

Re: RFR: 8311302: Allow for jlinking a custom runtime without packaged modules being present [v20]

2024-03-18 Thread Erik Joelsson
On Mon, 18 Mar 2024 18:40:36 GMT, Severin Gehwolf wrote: > What I mean to convey is that how the directory tree in `images/jdk` looks > like shouldn't change based on the `--enable-linkable-runtime-image` > configure flag. That is, there will be a `images/jdk/jmods` folder unless >

Re: RFR: 8311302: Allow for jlinking a custom runtime without packaged modules being present [v20]

2024-03-14 Thread Erik Joelsson
On Thu, 14 Mar 2024 20:54:32 GMT, Mandy Chung wrote: > About the configure options, > > ``` > --enable-keep-packaged-modules > enable keeping of packaged modules in jdk image > [enabled] > --enable-runtime-link-image > enable producing an

Re: RFR: 8311302: Allow for jlinking a custom runtime without packaged modules being present [v20]

2024-03-14 Thread Erik Joelsson
On Thu, 14 Mar 2024 14:27:47 GMT, Severin Gehwolf wrote: >> Severin Gehwolf has updated the pull request incrementally with one >> additional commit since the last revision: >> >> Fix comment in autoconf file > > make/Images.gmk line 33: > >> 31: include Modules.gmk >> 32: include Utils.gmk

Re: RFR: 8311302: Allow for jlinking a custom runtime without packaged modules being present [v20]

2024-03-14 Thread Erik Joelsson
On Thu, 14 Mar 2024 14:24:57 GMT, Severin Gehwolf wrote: >> Please review this patch which adds a jlink mode to the JDK which doesn't >> need the packaged modules being present. A.k.a run-time image based jlink. >> Fundamentally this patch adds an option to use `jlink` even though your JDK >>

Re: RFR: 8325621: Improve jspawnhelper version checks [v4]

2024-03-14 Thread Erik Joelsson
On Wed, 13 Mar 2024 17:11:25 GMT, Chad Rakoczy wrote: >> Fix for [8325621](https://bugs.openjdk.org/browse/JDK-8325621) >> >> Updates jspawnhelper to check that JDK version and jspawnhelper version are >> the same. Updates test to include check for version. Also tested manually by >>

Re: RFR: 8328074: Add jcheck whitespace checking for assembly files [v4]

2024-03-13 Thread Erik Joelsson
On Wed, 13 Mar 2024 11:59:36 GMT, Magnus Ihse Bursie wrote: >> As part of the ongoing effort to enable jcheck whitespace checking to all >> text files, it is now time to address assembly (.S) files. The hotspot >> assembly files were fixed as part of the hotspot mapfile removal, so only a >>

Re: RFR: 8325621: Improve jspawnhelper version checks [v2]

2024-03-12 Thread Erik Joelsson
On Mon, 11 Mar 2024 19:12:33 GMT, Chad Rakoczy wrote: >> Fix for [8325621](https://bugs.openjdk.org/browse/JDK-8325621) >> >> Updates jspawnhelper to check that JDK version and jspawnhelper version are >> the same. Updates test to include check for version. Also tested manually by >>

Re: RFR: 8325621: Improve jspawnhelper version checks [v2]

2024-03-11 Thread Erik Joelsson
On Mon, 11 Mar 2024 18:36:57 GMT, Aleksey Shipilev wrote: > > If you really want to require an exact match for jspawnhelper, then these 4 > > numbers aren't necessarily enough, but a rather arbitrarily chosen > > approximation. > > I think for our purposes, a version number quadruplet is

Re: RFR: 8325621: Improve jspawnhelper version checks

2024-03-11 Thread Erik Joelsson
On Mon, 11 Mar 2024 17:46:14 GMT, Chad Rakoczy wrote: > Fix for [8325621](https://bugs.openjdk.org/browse/JDK-8325621) > > Updates jspawnhelper to check that JDK version and jspawnhelper version are > the same. Updates test to include check for version. Also tested manually by > replacing

Re: RFR: 8311302: Allow for jlinking a custom runtime without packaged modules being present [v18]

2024-03-11 Thread Erik Joelsson
On Tue, 27 Feb 2024 15:23:09 GMT, Severin Gehwolf wrote: >> Please review this patch which adds a jlink mode to the JDK which doesn't >> need the packaged modules being present. A.k.a run-time image based jlink. >> Fundamentally this patch adds an option to use `jlink` even though your JDK >>

Re: RFR: 8311302: Allow for jlinking a custom runtime without packaged modules being present [v18]

2024-03-11 Thread Erik Joelsson
On Fri, 8 Mar 2024 17:36:33 GMT, Severin Gehwolf wrote: >> That was modelled similar to `jdk_jlink` target. It also does the removal. >> When building with `--enable-runtime-link-image`, the flow is: >> >> >> 1. Link the initial jdk image (current `images/jdk`). Output is >>

Re: RFR: 8327701: Remove the xlc toolchain [v2]

2024-03-08 Thread Erik Joelsson
On Fri, 8 Mar 2024 15:48:08 GMT, Magnus Ihse Bursie wrote: >> As of [JDK-8325880](https://bugs.openjdk.org/browse/JDK-8325880), building >> the JDK requires version 17 of IBM Open XL C/C++ (xlc). This is in effect >> clang by another name, and it uses the clang toolchain in the JDK build. >>

Re: RFR: 8327675: jspawnhelper should be built on all unix platforms

2024-03-08 Thread Erik Joelsson
On Fri, 8 Mar 2024 10:17:08 GMT, Magnus Ihse Bursie wrote: > We should match the building of jspawnhelper in > make/modules/java.base/Launcher.gmk with the usage for all unix platforms in > src/java.base/unix/classes/java/lang/ProcessImpl.java. > > Granted, the list of OSes in the makefile

Re: RFR: 8327460: Compile tests with the same visibility rules as product code [v2]

2024-03-06 Thread Erik Joelsson
On Wed, 6 Mar 2024 13:43:00 GMT, Magnus Ihse Bursie wrote: >> Currently, our symbol visibility handling for tests are sloppy; we only >> handle it properly on Windows. We need to bring it up to the same levels as >> product code. This is a prerequisite for >>

Integrated: 8326891: Prefer RPATH over RUNPATH for $ORIGIN rpaths in internal JDK binaries

2024-03-05 Thread Erik Joelsson
On Wed, 28 Feb 2024 19:29:13 GMT, Erik Joelsson wrote: > Executables and dynamic libraries on Linux can encode a search path that the > dynamic linker will use when looking up library dependencies, generally > referred to as an "rpath". In the JDK we use this with the $ORIGI

Re: RFR: 8326891: Prefer RPATH over RUNPATH for $ORIGIN rpaths in internal JDK binaries [v4]

2024-03-05 Thread Erik Joelsson
On Tue, 5 Mar 2024 07:16:10 GMT, David Holmes wrote: > Thanks for the further explanation and adding the comment. > > LGTM. Thanks! Does the release note also looks ok? I understand it needs to be reviewed together with the PR. - PR Comment:

Re: RFR: 8326891: Prefer RPATH over RUNPATH for $ORIGIN rpaths in internal JDK binaries [v4]

2024-03-04 Thread Erik Joelsson
I propose that we explicitly configure the JDK build to set RPATH instead of > RUNPATH for Linux binaries. This is done with the linker flag > "--disable-new-dtags". Erik Joelsson has updated the pull request incrementally with one additional commit since the last revision: bug ref

Re: RFR: 8326891: Prefer RPATH over RUNPATH for $ORIGIN rpaths in internal JDK binaries [v2]

2024-03-04 Thread Erik Joelsson
On Mon, 4 Mar 2024 14:53:21 GMT, Magnus Ihse Bursie wrote: >> make/autoconf/flags-cflags.m4 line 40: >> >>> 38: # Default works for linux, might work on other platforms as well. >>> 39: SHARED_LIBRARY_FLAGS='-shared' >>> 40: SET_EXECUTABLE_ORIGIN='-Wl,-rpath,\$$ORIGIN[$]1 >>>

Re: RFR: 8326891: Prefer RPATH over RUNPATH for $ORIGIN rpaths in internal JDK binaries [v3]

2024-03-04 Thread Erik Joelsson
I propose that we explicitly configure the JDK build to set RPATH instead of > RUNPATH for Linux binaries. This is done with the linker flag > "--disable-new-dtags". Erik Joelsson has updated the pull request incrementally with one additional commit since the last revision: Add comm

Re: RFR: 8326891: Prefer RPATH over RUNPATH for $ORIGIN rpaths in internal JDK binaries [v2]

2024-03-04 Thread Erik Joelsson
On Sun, 3 Mar 2024 22:09:51 GMT, David Holmes wrote: > I find it somewhat odd that we seem to be add odds with the general > programming community when it comes to this behaviour. Giving precedence to > `LD_LIBRARY_PATH` is the new behaviour, enabled via `--enable-new-dtags`; and > at some

Re: RFR: 8327218: Add an ability to specify modules which should have native access enabled

2024-03-04 Thread Erik Joelsson
On Mon, 4 Mar 2024 13:52:13 GMT, Jan Lahoda wrote: > Currently, JDK modules load by the bootstrap and platform ClassLoaders are > automatically granted the native access. I am working on an upgrade of JLine > inside the `jdk.internal.le` module, and I would like to replace the current >

Re: RFR: 8326891: Prefer RPATH over RUNPATH for $ORIGIN rpaths in internal JDK binaries [v2]

2024-03-01 Thread Erik Joelsson
I propose that we explicitly configure the JDK build to set RPATH instead of > RUNPATH for Linux binaries. This is done with the linker flag > "--disable-new-dtags". Erik Joelsson has updated the pull request incrementally with one additional commit since the last revision: Use @require

Re: RFR: 8326891: Prefer RPATH over RUNPATH for $ORIGIN rpaths in internal JDK binaries [v2]

2024-03-01 Thread Erik Joelsson
On Fri, 1 Mar 2024 06:30:14 GMT, David Holmes wrote: >> Erik Joelsson has updated the pull request incrementally with one additional >> commit since the last revision: >> >> Use @requires in test > > test/jdk/tools/launcher/RunpathTest.java line 27: > >&

Re: RFR: 8326891: Prefer RPATH over RUNPATH for $ORIGIN rpaths in internal JDK binaries

2024-02-29 Thread Erik Joelsson
On Thu, 29 Feb 2024 06:34:42 GMT, David Holmes wrote: > I can imagine it could be used to allow "hot patching" of the installed > JDK/JRE. Whether anyone has ever needed to do so is another matter. I suggest > at least adding a Release Note. Added release note. - PR Comment:

RFR: 8326891: Prefer RPATH over RUNPATH for $ORIGIN rpaths in internal JDK binaries

2024-02-28 Thread Erik Joelsson
Executables and dynamic libraries on Linux can encode a search path that the dynamic linker will use when looking up library dependencies, generally referred to as an "rpath". In the JDK we use this with the $ORIGIN feature to set search paths relative to the location of the binary itself.

Re: RFR: 8311302: Allow for jlinking a custom runtime without packaged modules being present [v18]

2024-02-27 Thread Erik Joelsson
On Tue, 27 Feb 2024 15:23:09 GMT, Severin Gehwolf wrote: >> Please review this patch which adds a jlink mode to the JDK which doesn't >> need the packaged modules being present. A.k.a run-time image based jlink. >> Fundamentally this patch adds an option to use `jlink` even though your JDK >>

Re: RFR: 8174269: Remove COMPAT locale data provider from JDK

2024-02-26 Thread Erik Joelsson
On Fri, 23 Feb 2024 21:24:10 GMT, Naoto Sato wrote: > This PR intends to remove the legacy `COMPAT` locale data from the JDK. The > `COMPAT` locale data was introduced for applications' migratory purposes > transitioning to `CLDR`. It is becoming a technical debt and now is the time > to

Re: RFR: 8326583: Remove over-generalized DefineNativeToolchain solution

2024-02-23 Thread Erik Joelsson
On Fri, 23 Feb 2024 16:23:43 GMT, Magnus Ihse Bursie wrote: > The idea of setting up general "toolchains" in the native build was good, but > it turned out that we really only need a single toolchain, with a single > twist: if it should use CC or CPP to link. This is better described by a >

Re: RFR: 8325950: Make sure all files in the JDK pass jcheck [v2]

2024-02-16 Thread Erik Joelsson
On Fri, 16 Feb 2024 12:43:25 GMT, Magnus Ihse Bursie wrote: >> Since jcheck only checks file in a commit, there is a possibility of us >> getting files in the repository that would not be accepted by jcheck. This >> can happen when extending the set of files checked by jcheck, or if jcheck >>

Re: RFR: 8325950: Make sure all files in the JDK pass jcheck

2024-02-15 Thread Erik Joelsson
On Thu, 15 Feb 2024 12:26:11 GMT, Magnus Ihse Bursie wrote: >> Since jcheck only checks file in a commit, there is a possibility of us >> getting files in the repository that would not be accepted by jcheck. This >> can happen when extending the set of files checked by jcheck, or if jcheck >>

Re: RFR: 8325558: Add jcheck whitespace checking for properties files

2024-02-09 Thread Erik Joelsson
On Fri, 9 Feb 2024 13:42:02 GMT, Magnus Ihse Bursie wrote: >> This is an attempt to finally implement the idea brought forward in >> JDK-8295729: Properties files is essentially source code. It should have >> the same whitespace checks as all other source code, so we don't get >> spurious

Re: RFR: JDK-8325189: Enable this-escape javac warning in java.base

2024-02-05 Thread Erik Joelsson
On Fri, 2 Feb 2024 23:36:41 GMT, Joe Darcy wrote: > After the "this-escape" lint warning was added to javac (JDK-8015831), the > base module was not updated to be able to compile with this warning enabled. > This PR makes the necessary changes to allow the base module to build with > the

Re: RFR: 8325163: Enable -Wpedantic on clang

2024-02-02 Thread Erik Joelsson
On Fri, 2 Feb 2024 15:22:03 GMT, Magnus Ihse Bursie wrote: > Inspired by (the later backed-out) > [JDK-8296115](https://bugs.openjdk.org/browse/JDK-8296115), I propose to > enable `-Wpedantic` for clang. This has already found some irregularities in > the code, like mistakenly using `#import`

Re: RFR: JDK-8325148: Enable restricted javac warning in java.base

2024-02-01 Thread Erik Joelsson
On Thu, 1 Feb 2024 21:10:48 GMT, Joe Darcy wrote: > The restricted javac warning is disabled for java.base, but could be enabled > by suppressing the warning in a handful of files. Marked as reviewed by erikj (Reviewer). - PR Review:

Re: [jdk22] RFR: Merge c7f1c97312f94b6dd6398a5e98dd0c8b63db4c9b

2024-01-16 Thread Erik Joelsson
On Tue, 16 Jan 2024 16:31:32 GMT, Henry Jen wrote: > CPU24_01 fixes. Marked as reviewed by erikj (Reviewer). - PR Review: https://git.openjdk.org/jdk22/pull/83#pullrequestreview-1826185706

Re: RFR: Merge bf7bd9a16c172bcb5ea6b24717a0429e12e2e3d1 [v2]

2024-01-16 Thread Erik Joelsson
On Tue, 16 Jan 2024 19:05:44 GMT, Henry Jen wrote: >> CPU24_01 fixes. > > Henry Jen has updated the pull request with a new target base due to a merge > or a rebase. The incremental webrev excludes the unrelated changes brought in > by the merge/rebase. The pull request contains eight

Re: RFR: 8323621: JDK build should exclude snippet class in java.lang.foreign

2024-01-12 Thread Erik Joelsson
On Fri, 12 Jan 2024 15:17:42 GMT, Per Minborg wrote: > This PR proposes to remove the snippet files in > `java/lang/foreign/snippet-files` from the build. make/modules/java.base/Java.gmk line 41: > 39: java/lang/classfile/snippet-files \ > 40:

Re: RFR: 8323529: Relativize test image dependencies in microbenchmarks

2024-01-11 Thread Erik Joelsson
On Thu, 11 Jan 2024 14:17:39 GMT, Erik Joelsson wrote: >> In principle, I think tests should be executed from their corresponding >> test-support directory. (I think there is some JBS issue for this that's >> been around for some while.) The rationale is that this i

Re: RFR: 8323529: Relativize test image dependencies in microbenchmarks

2024-01-11 Thread Erik Joelsson
On Thu, 11 Jan 2024 11:23:55 GMT, Magnus Ihse Bursie wrote: > In principle, I think tests should be executed from their corresponding > test-support directory. (I think there is some JBS issue for this that's been > around for some while.) The rationale is that this is a good directory for >

Re: RFR: 8323529: Relativize test image dependencies in microbenchmarks

2024-01-10 Thread Erik Joelsson
On Wed, 10 Jan 2024 15:10:58 GMT, Claes Redestad wrote: > JMH microbenchmarks may have dependencies on artifacts in the test image > outside of the benchmarks.jar. This includes native libraries (built into > `$TEST_IMAGE/micro/native`) and may soon include other test libraries like > wb.jar

Re: RFR: JDK-8319413: Start of release updates for JDK 23

2023-11-28 Thread Erik Joelsson
On Fri, 3 Nov 2023 23:42:03 GMT, Joe Darcy wrote: > Time to start making preparations for JDK 23. Build changes look good. - Marked as reviewed by erikj (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/16505#pullrequestreview-1754115586

Re: RFR: JDK-8317799 : AIX PPC64: FFI symbol lookup doesn't find symbols

2023-11-09 Thread Erik Joelsson
On Mon, 30 Oct 2023 10:54:48 GMT, suchismith1993 wrote: > 1. Adding required compiler flags. > 2. Adding required symbols. > > JBS-ISSUE : [JDK-8317799](https://bugs.openjdk.org/browse/JDK-8317799) > Problem: There is syslookup file which expects the required symbols to be > exported using

Re: RFR: JDK-8319122: Improve documentation of various Zip-file related APIs

2023-11-03 Thread Erik Joelsson
On Mon, 30 Oct 2023 17:54:13 GMT, Volker Simonis wrote: >> The various Zip/Jar-file related Java APIs have some long-standing >> differences or peculiarities with respect to the ZIP-file specification or >> compared to other implementations which should be documented in the API-doc. >> This

Re: RFR: 8318027: Support alternative name to jdk.internal.vm.compiler

2023-10-20 Thread Erik Joelsson
On Fri, 13 Oct 2023 16:28:19 GMT, Doug Simon wrote: > The Graal code base has > [renamed](https://github.com/oracle/graal/commit/1e41203d10db321f86723eac90f6cd0573b08b33) > its module to `jdk.compiler.graal` as part of preparations for Project > Galahad. Due to the way Java modules work, this

Re: RFR: 8317979: Use TZ database style abbreviations in the CLDR locale provider [v3]

2023-10-17 Thread Erik Joelsson
On Tue, 17 Oct 2023 16:52:12 GMT, Naoto Sato wrote: >> CLDR provides very few short names for time zones, such as PST/PDT. This >> will typically end up substituting names from the COMPAT provider. Once the >> COMPAT is removed, they will be displayed in the GMT format, i.e., >> GMT+XX:YY.

Re: RFR: 8317763: Follow-up to AVX512 intrinsics for Arrays.sort() PR [v4]

2023-10-12 Thread Erik Joelsson
On Wed, 11 Oct 2023 22:40:20 GMT, Sandhya Viswanathan wrote: >> I see now that this is an unrelated change. In that case please avoid >> changing whitespace in unrelated files for this PR. > > @erikj79 This space was inadvertently added as part of > (https://github.com/openjdk/jdk/pull/14227)

Re: RFR: 8317763: Follow-up to AVX512 intrinsics for Arrays.sort() PR [v4]

2023-10-11 Thread Erik Joelsson
On Wed, 11 Oct 2023 21:04:25 GMT, Srinivas Vamsi Parasa wrote: >> make/modules/java.base/Lib.gmk line 230: >> >>> 228: CFLAGS := $(CFLAGS_JDKLIB) $(LIBFFI_CFLAGS), \ >>> 229: LDFLAGS := $(LDFLAGS_JDKLIB) \ >>> 230: $(call SET_SHARED_LIBRARY_ORIGIN), \ >> >> If you

Re: RFR: 8317763: Follow-up to AVX512 intrinsics for Arrays.sort() PR [v4]

2023-10-11 Thread Erik Joelsson
On Wed, 11 Oct 2023 17:28:12 GMT, Srinivas Vamsi Parasa wrote: >> The goal of this PR is to address the follow-up comments to the SIMD >> accelerated sort PR (#14227) which implemented AVX512 intrinsics for >> Arrays.sort() methods. >> The proposed changes are: >> >> 1) Restriction of the

Re: Should we build jrt-fs.jar again with the "Build JDK" ?

2023-09-20 Thread erik . joelsson
Hello Andrew, The bootcycle-images target is AFAIK just a test. It's certainly not meant to be the authoritative way of building the JDK. Using JDK N-1 as bootjdk is the official way of producing a JDK of version JDK N. For convenience, and because it should work, we also allow JDK N. Vendors

Re: RFR: 8296246: Update Unicode Data Files to Version 15.1.0 [v3]

2023-09-18 Thread Erik Joelsson
On Mon, 18 Sep 2023 18:33:20 GMT, Naoto Sato wrote: >> This PR is to incorporate the latest Unicode 15.1, which was released >> yesterday. Besides the usual character data update, an upgraded >> implementation of RegEx which reflects the Indic Conjunct Break specified in >> the latest

Re: RFR: 8316421: libjava should load shell32.dll eagerly [v2]

2023-09-18 Thread Erik Joelsson
On Mon, 18 Sep 2023 18:10:12 GMT, Daniel JeliƄski wrote: >> Please review this patch that makes java.dll load shell32.dll earlier. >> Delay-loading requires some additional code (delayimp.lib), and offers no >> benefits since we always load shell32 during JVM startup. >> >> Other than

Re: RFR: 8296246: Update Unicode Data Files to Version 15.1.0 [v2]

2023-09-18 Thread Erik Joelsson
On Fri, 15 Sep 2023 16:56:48 GMT, Naoto Sato wrote: >> This PR is to incorporate the latest Unicode 15.1, which was released >> yesterday. Besides the usual character data update, an upgraded >> implementation of RegEx which reflects the Indic Conjunct Break specified in >> the latest

Integrated: 8267174: Many test files have the wrong Copyright header

2023-09-12 Thread Erik Joelsson
On Tue, 5 Sep 2023 22:49:41 GMT, Erik Joelsson wrote: > There are a number of files in the `test` directory that have an incorrect > copyright header, which includes the "classpath" exception text. This patch > removes that text from all test files that I could find it in.

Re: RFR: 8267174: Many test files have the wrong Copyright header

2023-09-12 Thread Erik Joelsson
On Tue, 5 Sep 2023 22:49:41 GMT, Erik Joelsson wrote: > There are a number of files in the `test` directory that have an incorrect > copyright header, which includes the "classpath" exception text. This patch > removes that text from all test files that I could find it in.

Re: RFR: 8267174: Many test files have the wrong Copyright header

2023-09-06 Thread Erik Joelsson
On Tue, 5 Sep 2023 23:12:51 GMT, Chris Plummer wrote: > I wonder if this is the right thing to do for the hprof files. I believe they > originated from some hprof tools that we no longer ship. 3rd parties might > choose to integrate them into their own tools. Do you think I should revert

RFR: 8267174: Many test files have the wrong Copyright header

2023-09-05 Thread Erik Joelsson
There are a number of files in the `test` directory that have an incorrect copyright header, which includes the "classpath" exception text. This patch removes that text from all test files that I could find it in. I did this using a combination of `sed` and `grep`. Reviewing this patch is

Re: Crash during optimizing exploded image with my patch

2023-09-01 Thread erik . joelsson
Hello Chen Liang, The exploded image optimization step runs the newly built JDK (in the exploded image) to generate data for itself. This means that if you change something fundamental in the JDK core libraries or the JVM, that may cause crashes in this build step. To diagnose further, you

Re: RFR: 8309130: x86_64 AVX512 intrinsics for Arrays.sort methods (int, long, float and double arrays) [v31]

2023-08-31 Thread Erik Joelsson
On Thu, 31 Aug 2023 18:45:39 GMT, Srinivas Vamsi Parasa wrote: >> The goal is to develop faster sort routines for x86_64 CPUs by taking >> advantage of AVX512 instructions. This enhancement provides an order of >> magnitude speedup for Arrays.sort() using int, long, float and double arrays.

Re: RFR: 8309130: x86_64 AVX512 intrinsics for Arrays.sort methods (int, long, float and double arrays) [v30]

2023-08-28 Thread Erik Joelsson
On Mon, 28 Aug 2023 21:27:25 GMT, Srinivas Vamsi Parasa wrote: >> The goal is to develop faster sort routines for x86_64 CPUs by taking >> advantage of AVX512 instructions. This enhancement provides an order of >> magnitude speedup for Arrays.sort() using int, long, float and double arrays.

Re: RFR: 8309130: x86_64 AVX512 intrinsics for Arrays.sort methods (int, long, float and double arrays) [v29]

2023-08-28 Thread Erik Joelsson
On Mon, 28 Aug 2023 22:42:50 GMT, Srinivas Vamsi Parasa wrote: >> make/modules/java.base/Lib.gmk line 239: >> >>> 237: >>> >>> 238: >>> 239: ifeq ($(call isTargetOs, linux)+$(call isTargetCpu, >>>

Integrated: 8314483: Optionally override copyright header in generated source

2023-08-25 Thread Erik Joelsson
On Fri, 18 Aug 2023 14:22:49 GMT, Erik Joelsson wrote: > In the JDK build we have various build tools that generate source code from > data files. For most of these tools, the source files are based on template > files, which already have copyright headers, but for some, the complete

Re: RFR: 8309130: x86_64 AVX512 intrinsics for Arrays.sort methods (int, long, float and double arrays) [v29]

2023-08-25 Thread Erik Joelsson
On Fri, 25 Aug 2023 01:57:41 GMT, Srinivas Vamsi Parasa wrote: >> The goal is to develop faster sort routines for x86_64 CPUs by taking >> advantage of AVX512 instructions. This enhancement provides an order of >> magnitude speedup for Arrays.sort() using int, long, float and double arrays.

Re: RFR: 8314483: Optionally override copyright header in generated source [v2]

2023-08-25 Thread Erik Joelsson
On Fri, 25 Aug 2023 06:45:25 GMT, Andrey Turbanov wrote: >> Erik Joelsson has updated the pull request incrementally with one additional >> commit since the last revision: >> >> Suggestion from dholmes > > make/jdk/src/classes/build/tools/cldrconverter/CLDRConv

Re: RFR: 8314483: Optionally override copyright header in generated source [v3]

2023-08-25 Thread Erik Joelsson
is providing the copyright header > programatically. For the latter, we would like to implement an override > mechanism in each tool so that we can change the copyright header from a > custom makefile. Erik Joelsson has updated the pull request incrementally with one additional commit si

Re: RFR: 8314483: Optionally override copyright header in generated source [v2]

2023-08-24 Thread Erik Joelsson
On Thu, 24 Aug 2023 04:46:31 GMT, David Holmes wrote: >> Erik Joelsson has updated the pull request incrementally with one additional >> commit since the last revision: >> >> Suggestion from dholmes > > make/jdk/src/classes/build/tools/generatelsrequivmaps/Equi

Re: RFR: 8314483: Optionally override copyright header in generated source [v2]

2023-08-24 Thread Erik Joelsson
is providing the copyright header > programatically. For the latter, we would like to implement an override > mechanism in each tool so that we can change the copyright header from a > custom makefile. Erik Joelsson has updated the pull request incrementally with one additional commit si

RFR: 8314483: Optionally override copyright header in generated source

2023-08-18 Thread Erik Joelsson
In the JDK build we have various build tools that generate source code from data files. For most of these tools, the source files are based on template files, which already have copyright headers, but for some, the complete source file is generated by the tool, which is providing the copyright

Re: RFR: 8314495: Update to use jtreg 7.3.1

2023-08-18 Thread Erik Joelsson
On Thu, 17 Aug 2023 07:24:14 GMT, Christian Stein wrote: > Please review the change to update to using jtreg 7.3,1. > > The primary change is to the `jib-profiles.js` file, which specifies the > version of jtreg to use, for those systems that rely on this file. In > addition, the

Re: RFR: 8312522: Implementation of Foreign Function & Memory API

2023-08-08 Thread Erik Joelsson
On Tue, 1 Aug 2023 10:29:06 GMT, Jorn Vernee wrote: > This patch contains the implementation of the foreign linker & memory API JEP > for Java 22. The initial patch is composed of commits brought over directly > from the [panama-foreign repo](https://github.com/openjdk/panama-foreign). > The

Re: RFR: 8311043: Remove trailing blank lines in source files

2023-06-29 Thread Erik Joelsson
On Thu, 29 Jun 2023 07:41:11 GMT, David Holmes wrote: > This seems to run contrary to the requirement that files end in a newline, > which git will complain about if the newline is missing. The patch is leaving exactly one newline at the end of the file. - PR Comment:

Re: RFR: 8311043: Remove trailing blank lines in source files

2023-06-29 Thread Erik Joelsson
On Wed, 28 Jun 2023 16:54:51 GMT, Leo Korinth wrote: > Remove trailing "blank" lines in source files. > > I like to use global-whitespace-cleanup-mode, but I can not use it if the > files are "dirty" to begin with. This fix will make more files "clean". I > also considered adding a check for

Re: RFR: 8298047: Remove all non-significant trailing whitespace from properties files [v2]

2023-06-26 Thread Erik Joelsson
On Sat, 24 Jun 2023 06:47:48 GMT, Vladimir Sitnikov wrote: > I've posted the suggetion to add .editorconfig on ide-support-dev, however, > the list does not seem to be active: > https://mail.openjdk.org/pipermail/ide-support-dev/2023-June/000281.html I think that sounds like a reasonable

Re: RFR: JDK-8310550: Adjust references to rt.jar

2023-06-21 Thread Erik Joelsson
On Wed, 21 Jun 2023 15:18:19 GMT, Matthias Baesken wrote: > There are a few references to rt.jar in comments and in the codebase itself. > Some of them might be removed or adjusted. The update to Java.gmk is good. - Marked as reviewed by erikj (Reviewer). PR Review:

Re: [jdk21] RFR: 8307858: [REDO] JDK-8307194 Add make target for optionally building a complete set of all JDK and hotspot libjvm static libraries

2023-06-20 Thread Erik Joelsson
On Fri, 16 Jun 2023 22:10:08 GMT, Daniel D. Daugherty wrote: > @erikj - You did a round of Mach5 testing on the JDK22 version of this fix. > Do you have plans to redo that testing for the JDK21 backport? I have done testing of the JDK 21 version of the patch and it's running cleanly.

Re: [jdk21] RFR: 8307858: [REDO] JDK-8307194 Add make target for optionally building a complete set of all JDK and hotspot libjvm static libraries

2023-06-20 Thread Erik Joelsson
On Fri, 16 Jun 2023 20:36:07 GMT, Jiangli Zhou wrote: > 8307858: [REDO] JDK-8307194 Add make target for optionally building a > complete set of all JDK and hotspot libjvm static libraries The changes look ok. - Marked as reviewed by erikj (Reviewer). PR Review:

Re: RFR: 8309880: Add support for linking libffi on Windows and Mac [v2]

2023-06-13 Thread Erik Joelsson
On Tue, 13 Jun 2023 17:09:30 GMT, Jorn Vernee wrote: >> Update the make/autoconf/lib-ffi.m4 script to support using libffi on >> Windows and Mac. >> >> For Windows I had to tweak `fallbackLinker.c` to be able to build: there was >> an import of `stdint.h` missing, and since it was using

Re: RFR: 8308286 Fix clang warnings in linux code [v5]

2023-06-12 Thread Erik Joelsson
On Sun, 11 Jun 2023 16:38:31 GMT, Artem Semenov wrote: >> When using the clang compiler to build OpenJDk on Linux, we encounter >> various "warnings as errors". >> They can be fixed with small changes. > > Artem Semenov has updated the pull request with a new target base due to a > merge or a

Re: RFR: 8307858: [REDO] JDK-8307194 Add make target for optionally building a complete set of all JDK and hotspot libjvm static libraries [v8]

2023-06-09 Thread Erik Joelsson
tial linking step for building static libraries with clang on > linux. >- On macosx, workaround the long argument issue for 'AR' with relative > path. > >Tested building jdk-image and static-libs-image on linux-x64 (for both gcc > and clang) and macosx-x64 (clang) man

Re: RFR: 8307858: [REDO] JDK-8307194 Add make target for optionally building a complete set of all JDK and hotspot libjvm static libraries [v7]

2023-06-09 Thread Erik Joelsson
> - Merge branch 'master' into JDK-8307858 > - Address comments/suggestions from @erikj79: >- Only do partial linking step for building static libraries with clang on > linux. > - On macosx, workaround the long argument issue for 'AR' with relative >

Re: RFR: 8309501: Remove workaround in bin/idea.sh for non standard JVMCI file layout

2023-06-05 Thread Erik Joelsson
On Mon, 5 Jun 2023 19:12:52 GMT, Tom Rodriguez wrote: > This allows bin/idea.sh to properly see the JVMCI files again. Marked as reviewed by erikj (Reviewer). - PR Review: https://git.openjdk.org/jdk/pull/14318#pullrequestreview-1463324474

Re: RFR: 8307858: [REDO] JDK-8307194 Add make target for optionally building a complete set of all JDK and hotspot libjvm static libraries [v4]

2023-06-02 Thread Erik Joelsson
On Thu, 1 Jun 2023 23:38:03 GMT, Jiangli Zhou wrote: > Sounds good for solving the macosx `ar` limitation differently. I'll change > that. We can also exclude the partial linking part for gcc (due the older > tool issue that you've found). Any concerns with including partial linking > step

Re: RFR: 8307858: [REDO] JDK-8307194 Add make target for optionally building a complete set of all JDK and hotspot libjvm static libraries [v4]

2023-06-01 Thread Erik Joelsson
On Fri, 26 May 2023 20:26:02 GMT, Jiangli Zhou wrote: > > Another possibility might be the user provided `BUILD_LDCXX` includes extra > > options in the testing build (?). If that's the case, we probably could > > define a separate `BUILD_LD_PARTIAL` with no added options. In our > >

Re: RFR: 8307858: [REDO] JDK-8307194 Add make target for optionally building a complete set of all JDK and hotspot libjvm static libraries [v4]

2023-05-24 Thread Erik Joelsson
On Mon, 22 May 2023 21:27:58 GMT, Jiangli Zhou wrote: >> Original description for JDK-8307194 change: >> - >> This PR is branched from the makefile changes for >> https://bugs.openjdk.org/browse/JDK-8303796 and contains the following for >> handling the JDK/hotspot static libraries: >> >>

Re: RFR: 8307858: [REDO] JDK-8307194 Add make target for optionally building a complete set of all JDK and hotspot libjvm static libraries [v4]

2023-05-24 Thread Erik Joelsson
On Fri, 19 May 2023 21:20:19 GMT, Erik Joelsson wrote: >> Jiangli Zhou has updated the pull request incrementally with one additional >> commit since the last revision: >> >> - Add $$($1_LD) $$($1_SYSROOT_LDFLAGS) to $1_VARDEPS if $(TOOLCHAIN_TYPE) >>

Re: RFR: JDK-8306584: Start of release updates for JDK 22

2023-05-23 Thread Erik Joelsson
On Thu, 20 Apr 2023 20:28:18 GMT, Joe Darcy wrote: > Time to get JDK 22 underway... Marked as reviewed by erikj (Reviewer). - PR Review: https://git.openjdk.org/jdk/pull/13567#pullrequestreview-1440532444

Re: RFR: 8307858: [REDO] JDK-8307194 Add make target for optionally building a complete set of all JDK and hotspot libjvm static libraries [v2]

2023-05-22 Thread Erik Joelsson
On Mon, 22 May 2023 19:40:00 GMT, Jiangli Zhou wrote: >> Original description for JDK-8307194 change: >> - >> This PR is branched from the makefile changes for >> https://bugs.openjdk.org/browse/JDK-8303796 and contains the following for >> handling the JDK/hotspot static libraries: >> >>

Re: RFR: 8307858: [REDO] JDK-8307194 Add make target for optionally building a complete set of all JDK and hotspot libjvm static libraries [v2]

2023-05-22 Thread Erik Joelsson
On Mon, 22 May 2023 19:21:52 GMT, Jiangli Zhou wrote: >> Thanks @erikj79. Could you please help provide some more info on the build >> failure: >> >> Which macOs version ran into the build issue? My mac is on Ventura 13.3.1 >> (a). It builds successfully for the `static-libs-image` target. >>

Re: RFR: 8308093: Disable language preview features use in JDK

2023-05-22 Thread Erik Joelsson
On Mon, 22 May 2023 10:01:55 GMT, Adam Sotona wrote: > This patch disables temporary use of language preview features in JDK. > Temporary enabled language preview features (to allow Pattern Matching for > switch use in the Classfile API library) are no more necessary. > All redundant use of

  1   2   >