Re: RFR: JDK-8283320: Error message for Windows libraries always points to --with-msvcr-dll no matter the actual file name

2022-03-17 Thread Magnus Ihse Bursie
On Thu, 17 Mar 2022 13:11:19 GMT, Julian Waters wrote: > TOOLCHAIN_SETUP_MSVC_DLL always points to --with-msvcr-dll if it couldn't > find the requested file, even if the dll being searched for was msvcp.dll for > instance. This small patch fixes the potentially confusing advice to point to > t

Build performance regressions

2022-03-17 Thread Magnus Ihse Bursie
It was recently pointed out to me by Robbin Ehn that the build time for exploded-image has undergone a major regression over the last two years. I have conducted a series of performance tests starting with jdk-15+24, and can confirm that sorry picture. :-( Despite certain individual gains in b

Re: RFR: 8204541: Correctly support AIX xlC 16.1 symbol visibility flags

2022-03-18 Thread Magnus Ihse Bursie
On Fri, 18 Mar 2022 01:50:56 GMT, Ichiroh Takiguchi wrote: > This change is just for AIX platform with IBM XL C/C++ 16.1. > By this change, lib's entry points are reduced by compilation and linkage > option changes. > > Without changes: > > $ dump -X32_64 -Tv lib/libawt.so | grep EXP | wc > 9

Re: RFR: 8204541: Correctly support AIX xlC 16.1 symbol visibility flags [v2]

2022-03-18 Thread Magnus Ihse Bursie
On Fri, 18 Mar 2022 08:03:11 GMT, Ichiroh Takiguchi wrote: >> This change is just for AIX platform with IBM XL C/C++ 16.1. >> By this change, lib's entry points are reduced by compilation and linkage >> option changes. >> >> Without changes: >> >> $ dump -X32_64 -Tv lib/libawt.so | grep EXP |

Re: RFR: 8257733: Move module-specific data from make to respective module [v9]

2022-03-18 Thread Magnus Ihse Bursie
> 18 mars 2022 kl. 11:04 skrev Alan Bateman : > > I can't tell if you are planning to integrate this or wait until there is > discussion on the locations proposed in the Informational JEP that you've > just submitted. Maybe you plan to just integrate and then adjust/move again > if needed? I

Re: RFR: 8257733: Move module-specific data from make to respective module [v10]

2022-03-21 Thread Magnus Ihse Bursie
d, even though this has nothing to do with the build. While > this is annoying, a worse problem is if the actual team that needs to review > the patch (i.e., the team owning the module) is missed in the review. > > ### Modules reviewed > > - [x] java.base > - [x] java.desktop &

Re: RFR: 8257733: Move module-specific data from make to respective module [v11]

2022-03-21 Thread Magnus Ihse Bursie
d, even though this has nothing to do with the build. While > this is annoying, a worse problem is if the actual team that needs to review > the patch (i.e., the team owning the module) is missed in the review. > > ### Modules reviewed > > - [x] java.base > - [x] java.desktop

Re: RFR: 8257733: Move module-specific data from make to respective module [v9]

2022-03-21 Thread Magnus Ihse Bursie
On Fri, 18 Mar 2022 21:24:43 GMT, Phil Race wrote: >> Magnus Ihse Bursie has updated the pull request incrementally with one >> additional commit since the last revision: >> >> Fix typos > > This doesn't seem right to me to put x11wrappergen into share. &

Re: RFR: 8276799: Implementation of JEP 422: Linux/RISC-V Port

2022-03-21 Thread Magnus Ihse Bursie
On Mon, 8 Nov 2021 11:17:47 GMT, Fei Yang wrote: > This PR implements JEP 422: Linux/RISC-V Port [1]. > The PR starts as a squashed merge of the > https://openjdk.java.net/projects/riscv-port branch. > > This has been tested with jtreg tier{1,2,3,4} and jcstress on HiFive > Unmatched board. Da

Re: RFR: 8257733: Move module-specific data from make to respective module [v12]

2022-03-21 Thread Magnus Ihse Bursie
d, even though this has nothing to do with the build. While > this is annoying, a worse problem is if the actual team that needs to review > the patch (i.e., the team owning the module) is missed in the review. > > ### Modules reviewed > > - [x] java.base > - [x] java.desktop &

Re: RFR: 8257733: Move module-specific data from make to respective module [v13]

2022-03-21 Thread Magnus Ihse Bursie
d, even though this has nothing to do with the build. While > this is annoying, a worse problem is if the actual team that needs to review > the patch (i.e., the team owning the module) is missed in the review. > > ### Modules reviewed > > - [x] java.base > - [x] java.desktop

Re: RFR: 8257733: Move module-specific data from make to respective module [v14]

2022-03-21 Thread Magnus Ihse Bursie
d, even though this has nothing to do with the build. While > this is annoying, a worse problem is if the actual team that needs to review > the patch (i.e., the team owning the module) is missed in the review. > > ### Modules reviewed > > - [x] java.base > - [x] java.desktop &

Integrated: 8257733: Move module-specific data from make to respective module

2022-03-21 Thread Magnus Ihse Bursie
On Thu, 3 Dec 2020 23:44:20 GMT, Magnus Ihse Bursie wrote: > A lot (but not all) of the data in make/data is tied to a specific module. > For instance, the publicsuffixlist is used by java.base, and fontconfig by > java.desktop. (A few directories, like mainmanifest, is *actually

RFR: 8283323: libharfbuzz optimization level results in extreme build times

2022-03-23 Thread Magnus Ihse Bursie
[JDK-8247872](https://bugs.openjdk.java.net/browse/JDK-8247872) (upgrade HarfBuzz to 2.7.2) caused build time to go up with 24 seconds on my reference linux machine. This was one of the four culprits that caused a 25-30% build time regression over the last two years. The problem here was that t

Re: RFR: 8283323: libharfbuzz optimization level results in extreme build times

2022-03-23 Thread Magnus Ihse Bursie
On Wed, 23 Mar 2022 12:25:08 GMT, Magnus Ihse Bursie wrote: > [JDK-8247872](https://bugs.openjdk.java.net/browse/JDK-8247872) (upgrade > HarfBuzz to 2.7.2) caused build time to go up with 24 seconds on my reference > linux machine. This was one of the four culprits that caused a 25-

Re: RFR: 8283323: libharfbuzz optimization level results in extreme build times

2022-03-23 Thread Magnus Ihse Bursie
On Wed, 23 Mar 2022 19:35:22 GMT, Phil Race wrote: >> [JDK-8247872](https://bugs.openjdk.java.net/browse/JDK-8247872) (upgrade >> HarfBuzz to 2.7.2) caused build time to go up with 24 seconds on my >> reference linux machine. This was one of the four culprits that caused a >> 25-30% build time

Re: RFR: 8283323: libharfbuzz optimization level results in extreme build times [v2]

2022-03-23 Thread Magnus Ihse Bursie
ntal, and just seemed good at the time. > > This patch changes the optimization level to `SIZE` (which is the closest > thing we have to no optimization level) on gcc. Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last

Re: RFR: 8283575: Check for GNU time fails for version >1.7

2022-03-23 Thread Magnus Ihse Bursie
On Wed, 23 Mar 2022 15:35:44 GMT, Erik Joelsson wrote: > The version output of GNU time changed from "GNU time" to "GNU Time" in > version 1.8. We need to update our check for identifying GNU time to handle > this. I usually handle cases like this by prefixing with a comment: # Additional

Re: RFR: 8283323: libharfbuzz optimization level results in extreme build times [v2]

2022-03-23 Thread Magnus Ihse Bursie
On Wed, 23 Mar 2022 21:13:30 GMT, Magnus Ihse Bursie wrote: >> [JDK-8247872](https://bugs.openjdk.java.net/browse/JDK-8247872) (upgrade >> HarfBuzz to 2.7.2) caused build time to go up with 24 seconds on my >> reference linux machine. This was one of the four culprits that

Re: RFR: 8283323: libharfbuzz optimization level results in extreme build times [v2]

2022-03-23 Thread Magnus Ihse Bursie
On Wed, 23 Mar 2022 22:37:55 GMT, Phil Race wrote: >> Magnus Ihse Bursie has updated the pull request incrementally with one >> additional commit since the last revision: >> >> Restore HIGHEST for entire lib, just set SIZE to two files > > make/modules/java.

Re: RFR: 8283323: libharfbuzz optimization level results in extreme build times [v3]

2022-03-23 Thread Magnus Ihse Bursie
ntal, and just seemed good at the time. > > This patch changes the optimization level to `SIZE` (which is the closest > thing we have to no optimization level) on gcc. Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the

Re: RFR: 8283323: libharfbuzz optimization level results in extreme build times [v3]

2022-03-23 Thread Magnus Ihse Bursie
On Wed, 23 Mar 2022 23:38:52 GMT, Sergey Bylokhov wrote: >> Magnus Ihse Bursie has updated the pull request incrementally with one >> additional commit since the last revision: >> >> Update comment to show we don't care about these files. > > Do w

Re: RFR: 8283323: libharfbuzz optimization level results in extreme build times [v3]

2022-03-24 Thread Magnus Ihse Bursie
On Thu, 24 Mar 2022 07:38:34 GMT, Sergey Bylokhov wrote: >>> @mrserb Phil said that we don't even use the subset part of harfbuzz. >>> >>> And unless you're backing up your claim that this patch is changing runtime >>> characteristic with data, that's just a guess, just like the initial >>> op

Re: RFR: 8283575: Check for GNU time fails for version >1.7 [v2]

2022-03-24 Thread Magnus Ihse Bursie
ated the pull request incrementally with one additional > commit since the last revision: > > Update make/autoconf/basic_tools.m4 > > Co-authored-by: Magnus Ihse Bursie Marked as reviewed by ihse (Reviewer). - PR: https://git.openjdk.java.net/jdk/pull/7925

Integrated: 8283323: libharfbuzz optimization level results in extreme build times

2022-03-24 Thread Magnus Ihse Bursie
On Wed, 23 Mar 2022 12:25:08 GMT, Magnus Ihse Bursie wrote: > [JDK-8247872](https://bugs.openjdk.java.net/browse/JDK-8247872) (upgrade > HarfBuzz to 2.7.2) caused build time to go up with 24 seconds on my reference > linux machine. This was one of the four culprits that caused a 25-

Re: Is --with-zlib=bundled broken on MacOS aarch64 12.2.1?

2022-03-28 Thread Magnus Ihse Bursie
On 2022-03-28 09:03, David Holmes wrote: On 28/03/2022 4:56 pm, Alan Bateman wrote: On 28/03/2022 07:46, David Holmes wrote: Hi Jai, It isn't obvious to me that the bundled sources are actually intended to build on macOS. There's no include of unistd.h to get the lseek definition. I think th

Re: RFR: 8283723: Update Visual Studio 2022 to version 17.1.0 for Oracle builds on Windows

2022-03-28 Thread Magnus Ihse Bursie
On Sun, 27 Mar 2022 05:08:52 GMT, Mikael Vidstedt wrote: > Oracle is updating the version of Visual Studio for building the JDK on > Windows to Visual Studio 2022 17.1.0. > > This change adds support for building devkits based on VS 2022. Instead of > creating a new script file for that I deci

Re: RFR: 8283723: Update Visual Studio 2022 to version 17.1.0 for Oracle builds on Windows [v3]

2022-03-29 Thread Magnus Ihse Bursie
On Mon, 28 Mar 2022 16:43:30 GMT, Mikael Vidstedt wrote: >> Oracle is updating the version of Visual Studio for building the JDK on >> Windows to Visual Studio 2022 17.1.0. >> >> This change adds support for building devkits based on VS 2022. Instead of >> creating a new script file for that I

Re: Is --with-zlib=bundled broken on MacOS aarch64 12.2.1?

2022-03-29 Thread Magnus Ihse Bursie
On 2022-03-29 03:42, Jaikiran Pai wrote: Hello Magnus, On 28/03/22 5:21 pm, Magnus Ihse Bursie wrote: On 2022-03-28 09:03, David Holmes wrote: On 28/03/2022 4:56 pm, Alan Bateman wrote: On 28/03/2022 07:46, David Holmes wrote: Hi Jai, It isn't obvious to me that the bundled source

RFR: 8283901: Introduce "make doctor" to diagnose build environment problems

2022-03-29 Thread Magnus Ihse Bursie
When a user has problems with their build environment that trips up their builds, the cause is often one of just a few "popular" gotchas. For us working with the build system, we've seen them all before, but for the individual user, it's often the first time, and it can be really frustrating to

Re: RFR: 8284507: GHA: Only check test results if testing was not skipped

2022-04-07 Thread Magnus Ihse Bursie
On Thu, 7 Apr 2022 07:53:38 GMT, Christoph Langer wrote: > In GitHub Actions the step "Check that all tests executed successfully" will > be marked as failing when the "Run tests" step did not run but some earlier > step already failed. This is irritating and it can be corrected by doing the >

Re: RFR: 8284437: Building from different users/workspace is not always deterministic [v2]

2022-04-07 Thread Magnus Ihse Bursie
On Wed, 6 Apr 2022 13:30:28 GMT, Andrew Leonard wrote: >> This PR fixes the non-deterministic behavior when building on linux with >> different userids or within >> different workspace folders. >> It fixes the following issues: >> - MakeZipReproducible.java used to produce reproducible src.zip r

Re: RFR: 8284437: Building from different users/workspace is not always deterministic [v2]

2022-04-08 Thread Magnus Ihse Bursie
On Thu, 7 Apr 2022 20:15:12 GMT, Erik Joelsson wrote: >> @magicus >> So I did think about this, and the alternative I think would be to hard code >> a list of which object files are the output from assembly files, of which >> there is about a dozen. Unless we could capture somehow the list of

Re: RFR: 8284437: Building from different users/workspace is not always deterministic [v2]

2022-04-08 Thread Magnus Ihse Bursie
On Fri, 8 Apr 2022 08:14:18 GMT, Magnus Ihse Bursie wrote: >> It would certainly be possible to identify the objects created from assembly >> source files based on file extensions, but it wouldn't help. The command >> line would still be dependent on the current worki

Re: RFR: 8265315: Support for CLDR version 41

2022-04-08 Thread Magnus Ihse Bursie
On Thu, 7 Apr 2022 21:20:20 GMT, Naoto Sato wrote: > This is to upgrade the CLDR data from version 39 to version 41 which was > released yesterday. The vast majority of the changes are basically replacing > the CLDR data, along with tools/testcase alignments. Here is the link to CLDR > v41's r

Re: RFR: 8284437: Building from different users/workspace is not always deterministic [v2]

2022-04-08 Thread Magnus Ihse Bursie
@magicus thank you for looking at this, in hindsight I should have pinged you to review this as well. Technically Erik's approval is enough, but I do appreciate if I can get at least 24h to have a look at build changes that touches delicate build logic. It usually takes more than one of us t

Re: RFR: 8242181: [Linux] Show source information when printing native stack traces in hs_err files [v8]

2022-04-08 Thread Magnus Ihse Bursie
On Fri, 8 Apr 2022 13:02:00 GMT, Erik Joelsson wrote: >> Christian Hagedorn has updated the pull request with a new target base due >> to a merge or a rebase. The pull request now contains 60 commits: >> >> - Merge branch 'master' into JDK-8242181 >> - Fix build, add GCC flag gdwarf-4 to excl

Re: RFR: 8284437: Building from different users/workspace is not always deterministic [v2]

2022-04-08 Thread Magnus Ihse Bursie
On Wed, 6 Apr 2022 13:30:28 GMT, Andrew Leonard wrote: >> This PR fixes the non-deterministic behavior when building on linux with >> different userids or within >> different workspace folders. >> It fixes the following issues: >> - MakeZipReproducible.java used to produce reproducible src.zip r

Re: RFR: 8284437: Building from different users/workspace is not always deterministic [v2]

2022-04-08 Thread Magnus Ihse Bursie
On Fri, 8 Apr 2022 14:10:05 GMT, Maxim Kartashev wrote: >> Andrew Leonard has updated the pull request incrementally with one >> additional commit since the last revision: >> >> Trigger checks > > I did some experiments both with `gcc` and `clang`. Both respect the `.file` > directive and pu

RFR: 8284588: Remove GensrcCommonLangtools.gmk

2022-04-08 Thread Magnus Ihse Bursie
There's been unnecessary (near) duplication of functionality, and messy logic, in the langtools gensrc step, for a long time. (Basically since we got rid of the mercurial forest...) This is a first attempt at cleaning this up. The file GensrcCommonLangtools.gmk is removed. This contained three

Re: RFR: 8265315: Support for CLDR version 41

2022-04-08 Thread Magnus Ihse Bursie
On Thu, 7 Apr 2022 21:20:20 GMT, Naoto Sato wrote: > This is to upgrade the CLDR data from version 39 to version 41 which was > released yesterday. The vast majority of the changes are basically replacing > the CLDR data, along with tools/testcase alignments. Here is the link to CLDR > v41's r

Re: RFR: 8284588: Remove GensrcCommonLangtools.gmk

2022-04-08 Thread Magnus Ihse Bursie
On Fri, 8 Apr 2022 16:59:37 GMT, Erik Joelsson wrote: >> There's been unnecessary (near) duplication of functionality, and messy >> logic, in the langtools gensrc step, for a long time. (Basically since we >> got rid of the mercurial forest...) >> >> This is a first attempt at cleaning this up

Re: RFR: 8284588: Remove GensrcCommonLangtools.gmk [v2]

2022-04-08 Thread Magnus Ihse Bursie
needed to be slightly > modified to accept the same syntax as the JDK version of this tool.) > > A reasonable follow-up is to research if the two SetupCompileProperties tools > can be unified into one. Magnus Ihse Bursie has updated the pull request incrementally with one

Integrated: 8284588: Remove GensrcCommonLangtools.gmk

2022-04-08 Thread Magnus Ihse Bursie
On Fri, 8 Apr 2022 14:57:02 GMT, Magnus Ihse Bursie wrote: > There's been unnecessary (near) duplication of functionality, and messy > logic, in the langtools gensrc step, for a long time. (Basically since we got > rid of the mercurial forest...) > > This is a first atte

Re: RFR: 8284437: Building from different users/workspace is not always deterministic [v2]

2022-04-08 Thread Magnus Ihse Bursie
On Fri, 8 Apr 2022 14:48:41 GMT, Andrew Leonard wrote: >> I am not sure why without the explicit .file directive that the FILE symbol >> in the ELF info contains an entry pointing to the .o object file, here's >> what it was before: >> >> 31712: 0 FILELOCAL DEFAULT

Re: RFR: 8284661: Reproducible assembly builds without relative linking [v3]

2022-04-11 Thread Magnus Ihse Bursie
On Mon, 11 Apr 2022 15:41:20 GMT, Andrew Leonard wrote: >> This PR removes the need for relative object file linking introduced by >> JDK-8284437 for linux libraries, by specifying >> .file directives in the linux .S source files. The >> source files specify a .file ASSEMBLY_SRC_FILE >> where

Re: RFR: 8284720: IntelliJ: JIRA integration

2022-04-12 Thread Magnus Ihse Bursie
On Tue, 12 Apr 2022 04:44:15 GMT, Daniel Jeliński wrote: > This patch adds clickable link to commit messages in IntelliJ's git log. > Example result: > ![image](https://user-images.githubusercontent.com/30433125/162882312-6a9c7666-075d-47b7-9db5-22670b885e7b.png) Clever idea. - Ma

Re: RFR: 8284622: Update versions of some Github Actions used in JDK workflow

2022-04-12 Thread Magnus Ihse Bursie
On Sat, 9 Apr 2022 07:10:50 GMT, Christoph Langer wrote: > Let's update some github actions versions. No really interesting or breaking > changes but we should stay current. Looks OK. But there is really a LOT of redundancy in this file! :-( It is in desperate need of some refactoring to keep

Re: RFR: 8284661: Reproducible assembly builds without relative linking [v3]

2022-04-12 Thread Magnus Ihse Bursie
On Mon, 11 Apr 2022 15:41:20 GMT, Andrew Leonard wrote: >> This PR removes the need for relative object file linking introduced by >> JDK-8284437 for linux libraries, by specifying >> .file directives in the linux .S source files. The >> source files specify a .file ASSEMBLY_SRC_FILE >> where

Re: RFR: 8284661: Reproducible assembly builds without relative linking [v3]

2022-04-12 Thread Magnus Ihse Bursie
On Mon, 11 Apr 2022 15:41:20 GMT, Andrew Leonard wrote: >> This PR removes the need for relative object file linking introduced by >> JDK-8284437 for linux libraries, by specifying >> .file directives in the linux .S source files. The >> source files specify a .file ASSEMBLY_SRC_FILE >> where

Why we use specific compiler versions - was: Re: JDK-8284772 - was RE: [jdk17] RFR: 8269148: Update minor GCC version in GitHub Actions pipeline

2022-04-13 Thread Magnus Ihse Bursie
I disagree completely. We had it this way in mainline originally, but it was fixed in https://bugs.openjdk.java.net/browse/JDK-8256393. As you might know, I'm not too fond of the GHA solution, since we can't debug issues with Github's hosts. Nevertheless, many users look at the GHA results as

Re: fixpath seems to be deleting path separators when paths are read from files

2022-04-13 Thread Magnus Ihse Bursie
On 2022-04-13 05:39, Julian Waters wrote: Recently I've been getting build failures on my Windows device that go something along the lines of: /msys64/ucrt64/bin/../lib/gcc/x86_64-w64-mingw32/.../x86_64-w64-mingw32/bin/ld.exe: cannot find d:eclipseworkspacehotspotjdkbuildwindows-x86_64-server-

Re: RFR: 8284752: Zero does not build on Mac OS X due to missing os::current_thread_enable_wx implementation

2022-04-13 Thread Magnus Ihse Bursie
On 2022-04-12 15:21, David Holmes wrote: On Tue, 12 Apr 2022 11:31:03 GMT, Johannes Bechberger wrote: Adds an implementation of the missing method (guarded with `defined(AARCH64) && defined(__APPLE__)`) and fixes the compilation issues on Mac M1. Looks good and trivial. It seems apparent t

Re: RFR: 8284661: Reproducible assembly builds without relative linking [v4]

2022-04-13 Thread Magnus Ihse Bursie
On Wed, 13 Apr 2022 11:30:14 GMT, Andrew Leonard wrote: >> This PR removes the need for relative object file linking introduced by >> JDK-8284437 for linux libraries, by specifying >> .file directives in the linux .S source files. The >> source files specify a .file ASSEMBLY_SRC_FILE >> where

Re: fixpath seems to be deleting path separators when paths are read from files

2022-04-14 Thread Magnus Ihse Bursie
tents though You can modify make/scripts/fixpath.sh, and remove/comment out the line rm -rf $TEMPDIRS in the cleanup trap to keep it for post-mortem debugging. /Magnus best regards, Julian On Wed, Apr 13, 2022 at 7:04 PM Magnus Ihse Bursie wrote: On 2022-04-13 05:39, Julian Wat

Re: RFR: 8284661: Reproducible assembly builds without relative linking [v6]

2022-04-14 Thread Magnus Ihse Bursie
On Thu, 14 Apr 2022 12:07:06 GMT, Andrew Leonard wrote: >> This PR removes the need for relative object file linking introduced by >> JDK-8284437 for linux libraries, by specifying >> .file directives in the linux .S source files. The >> source files specify a .file ASSEMBLY_SRC_FILE >> where

Re: RFR: 8284853: Fix various 'expected' typo [v2]

2022-04-14 Thread Magnus Ihse Bursie
On Thu, 14 Apr 2022 09:28:17 GMT, Andrey Turbanov wrote: >> Found various typos of expected: `exepected`, `exept`, `epectedly`, >> `expeced`, `Unexpeted`, etc. > > Andrey Turbanov has updated the pull request incrementally with one > additional commit since the last revision: > > 8284853: Fi

RFR: 8284891: Fix typos in build system files

2022-04-14 Thread Magnus Ihse Bursie
I ran `codespell` on the `make` directory, and accepted those changes where it indeed discovered real typos. (Due to false positives this can unfortunately not be run automatically) Most of the fixes are in comments. A few are in messages aimed at the user. - Commit messages: - 8

Integrated: 8284891: Fix typos in build system files

2022-04-14 Thread Magnus Ihse Bursie
On Thu, 14 Apr 2022 16:05:48 GMT, Magnus Ihse Bursie wrote: > I ran `codespell` on the `make` directory, and accepted those changes where > it indeed discovered real typos. > > (Due to false positives this can unfortunately not be run automatically) > > Most of the fixes

RFR: 8284999: Remove remaining files in src/samples

2022-04-19 Thread Magnus Ihse Bursie
JEP 298 was about removing demos and samples. Unfortunately, [JDK-8173801](https://bugs.openjdk.java.net/browse/JDK-8173801) which should have removed all files in src/samples, left a few non-source files (key stores and images). These should be removed. - Commit messages: - 82849

Re: RFR: 8284949: riscv: Add Zero support for the 32-bit RISC-V architecture [v2]

2022-04-19 Thread Magnus Ihse Bursie
On Tue, 19 Apr 2022 08:47:18 GMT, Feilong Jiang wrote: >> This patch adds Zero support for the 32-bit RISC-V architecture. >> >> Additional tests: >> >> - [x] Linux zero RISCV32 cross-compilation >> - [x] Resulting binaries run on QEMU User mode without problems > > Feilong Jiang has updated th

Re: RFR: 8284539: Configure --with-source-date=version fails on MacOS

2022-04-19 Thread Magnus Ihse Bursie
On Thu, 14 Apr 2022 16:13:59 GMT, Andrew Leonard wrote: > JDK-8282769 added support for more ISO-8601 formats, but remove handling of > just a date "-MM-DD" being present, which is the case for a configure > using --with-source-date=version which uses the date string from > version-numbers

Re: RFR: 8284890: Support for Do not fragment IP socket options [v2]

2022-04-19 Thread Magnus Ihse Bursie
On Fri, 15 Apr 2022 11:49:29 GMT, Michael McMahon wrote: >> Hi, >> >> Could I get the following PR review please? It adds a new JDK specific >> extended socket option >> called IP_DONTFRAGMENT, which disables IP packet fragmentation in both IPv4 >> and IPv6 >> UDP sockets (NIO DatagramChannels

Re: Why we use specific compiler versions - was: Re: JDK-8284772 - was RE: [jdk17] RFR: 8269148: Update minor GCC version in GitHub Actions pipeline

2022-04-19 Thread Magnus Ihse Bursie
On 2022-04-14 19:42, Andrew Hughes wrote: On 12:57 Wed 13 Apr , Magnus Ihse Bursie wrote: I disagree completely. We had it this way in mainline originally, but it was fixed in https://bugs.openjdk.java.net/browse/JDK-8256393. Prior to this patch, it seems there were no GCC version

Integrated: 8284999: Remove remaining files in src/samples

2022-04-19 Thread Magnus Ihse Bursie
On Tue, 19 Apr 2022 10:41:07 GMT, Magnus Ihse Bursie wrote: > JEP 298 was about removing demos and samples. Unfortunately, > [JDK-8173801](https://bugs.openjdk.java.net/browse/JDK-8173801) which should > have removed all files in src/samples, left a few non-source files (key >

RFR: 8285093: Introduce UTIL_ARG_WITH

2022-04-19 Thread Magnus Ihse Bursie
Analogous to `UTIL_ARG_ENABLE`, we need a `UTIL_ARG_WITH` which wraps ´AC_ARG_WITH`, provides a declarative rather than programmatic way of handling configure arguments. It can also make sure that all edge cases are covered, and that we treat arguments consistently. This PR contains the implem

Integrated: 8285093: Introduce UTIL_ARG_WITH

2022-04-20 Thread Magnus Ihse Bursie
On Tue, 19 Apr 2022 20:38:31 GMT, Magnus Ihse Bursie wrote: > Analogous to `UTIL_ARG_ENABLE`, we need a `UTIL_ARG_WITH` which wraps > ´AC_ARG_WITH`, provides a declarative rather than programmatic way of > handling configure arguments. It can also make sure that all edge cases are

Re: RFR: 8283324: CLDRConverter run time increased by 3x

2022-04-21 Thread Magnus Ihse Bursie
On Mon, 18 Apr 2022 23:16:18 GMT, Naoto Sato wrote: > Fixing performance regression caused by the fix to > https://bugs.openjdk.java.net/browse/JDK-8176706. The fix introduced extra > looping through the resource map multiple times which was not necessary. The > execution time of the tool now

RFR: 8285919: Remove debug printout from JDK-8285093

2022-04-29 Thread Magnus Ihse Bursie
A debug printout in configure was introduced in JDK-8285093. It should be removed. - Commit messages: - 8285919: Remove debug printout from JDK-8285093 Changes: https://git.openjdk.java.net/jdk/pull/8467/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=8467&range=00 I

Integrated: 8285919: Remove debug printout from JDK-8285093

2022-04-29 Thread Magnus Ihse Bursie
On Fri, 29 Apr 2022 12:43:02 GMT, Magnus Ihse Bursie wrote: > A debug printout in configure was introduced in JDK-8285093. It should be > removed. This pull request has now been integrated. Changeset: 64225e19 Author:Magnus Ihse Bursie URL: https://git.openjdk.java.net/jdk/

Re: RFR: 8282828: CDS uncompressed oops archive is not deterministic

2022-05-02 Thread Magnus Ihse Bursie
On Fri, 29 Apr 2022 22:50:45 GMT, Ioi Lam wrote: > During `java -Xshare:dump -XX:-UseCompressedOops`, the location of the Java > heap is chosen by the OS. Due to Address Space Layout Randomization, the heap > will always start at a different location. This causes the archive for > uncompressed

Re: RFR: JDK-8285730: unify _WIN32_WINNT settings [v4]

2022-05-06 Thread Magnus Ihse Bursie
On Wed, 4 May 2022 08:00:08 GMT, Matthias Baesken wrote: >> Currently we set _WIN32_WINNT at various places in the codebase; this is >> used to target a minimum Windows version we want to support. See also for >> more detailled information : >> https://docs.microsoft.com/en-us/windows/win32/win

Fwd: JDK 19+21 early-access build is reproducible

2022-05-09 Thread Magnus Ihse Bursie
eproducible including the command-line tools, demos, API documentation, JMOD archives, native libraries, and man pages -- even when using a different build path. Note that I didn't test on macOS or Windows. A big thank you to Magnus Ihse Bursie and Andrew Leonard for doing much of the work to

Re: RFR: 8286429: jpackageapplauncher build fails intermittently in Tier[45]

2022-05-10 Thread Magnus Ihse Bursie
On Tue, 10 May 2022 01:36:06 GMT, David Holmes wrote: >> The way LauncherCommon.gmk is currently written, it's only meant to be >> included from "make/module//Launcher.gmk", or at least only from one >> single place for each module. This is because the man page generation that >> happens in La

Re: RFR: 8286429: jpackageapplauncher build fails intermittently in Tier[45]

2022-05-10 Thread Magnus Ihse Bursie
On Mon, 9 May 2022 23:18:47 GMT, Erik Joelsson wrote: > The way LauncherCommon.gmk is currently written, it's only meant to be > included from "make/module//Launcher.gmk", or at least only from one > single place for each module. This is because the man page generation that > happens in Launch

Re: RFR: 8286430: make test TEST="gtest:" exits with error when it shouldn't [v2]

2022-05-10 Thread Magnus Ihse Bursie
On Tue, 10 May 2022 08:46:44 GMT, Severin Gehwolf wrote: >> `make test TEST="gtest:> `1.10.0`. It expects `suites` to be present in the google test output >> whereas the OpenJDK build infra code expects `cases`. I'm not sure when/if >> that changed, but here is a proposed fix. >> >> Thoughts?

Re: RFR: 8286562: GCC 12 reports some compiler warnings [v2]

2022-05-11 Thread Magnus Ihse Bursie
On Wed, 11 May 2022 08:40:21 GMT, Yasumasa Suenaga wrote: >> I saw some compiler warnings when I tried to build OpenJDK with GCC 12.0.1 >> on Fedora 36. >> As you can see, the warnings spreads several areas. Let me know if I should >> separate them by area. >> >> * -Wstringop-overflow >> *

Re: RFR: 8286582: Build fails on macos aarch64 when using --with-zlib=bundled

2022-05-11 Thread Magnus Ihse Bursie
On Wed, 11 May 2022 11:38:31 GMT, Jaikiran Pai wrote: > Can I please get a review of this change which fixes build failures on macos > when using `--with-zlib=bundled`? > > With this change the build now passes (tested both with bundled and system > zlib variants). > > tier1, tier2 and tier3

Re: RFR: 8244681: Add a warning for possibly lossy conversion in compound assignments [v3]

2022-05-11 Thread Magnus Ihse Bursie
On Wed, 11 May 2022 07:45:39 GMT, Adam Sotona wrote: >> Please review this patch adding new lint option, **lossy-conversions**, to >> javac to warn about type casts in compound assignments with possible lossy >> conversions. >> >> The new lint warning is shown if the type of the right-hand ope

Re: RFR: 8244681: Add a warning for possibly lossy conversion in compound assignments [v3]

2022-05-11 Thread Magnus Ihse Bursie
On Wed, 11 May 2022 13:05:45 GMT, Erik Gahlin wrote: >> make/modules/jdk.jfr/Java.gmk line 26: >> >>> 24: # >>> 25: >>> 26: DISABLED_WARNINGS_java += exports lossy-conversions >> >> Note that with the fix of JDK-8286392 (and JDK-8286396) the >> `lossy-conversions` warning should not be disabl

Re: RFR: 8286562: GCC 12 reports some compiler warnings [v2]

2022-05-11 Thread Magnus Ihse Bursie
On 2022-05-11 16:01, Kim Barrett wrote: Globally disabling use-after-free warnings for this package seems really questionable. If these are problems in the code, just suppressing the warning and leaving the problems to bite us seems like a bad idea. And the problems ought to be reported upstream

Re: RFR: 8286582: Build fails on macos aarch64 when using --with-zlib=bundled [v2]

2022-05-11 Thread Magnus Ihse Bursie
On Wed, 11 May 2022 15:03:56 GMT, Lance Andersen wrote: >> Jaikiran Pai has updated the pull request incrementally with four additional >> commits since the last revision: >> >> - copyright years >> - disable format-nonliteral warning when building LIBSPLASHSCREEN with >> bundled zlib >> -

Re: RFR: 8286582: Build fails on macos aarch64 when using --with-zlib=bundled [v2]

2022-05-11 Thread Magnus Ihse Bursie
On Wed, 11 May 2022 14:24:38 GMT, Jaikiran Pai wrote: >> Can I please get a review of this change which fixes build failures on macos >> when using `--with-zlib=bundled`? >> >> With this change the build now passes (tested both with bundled and system >> zlib variants). >> >> tier1, tier2 and

Re: RFR: 8286582: Build fails on macos aarch64 when using --with-zlib=bundled [v2]

2022-05-11 Thread Magnus Ihse Bursie
On Wed, 11 May 2022 19:14:54 GMT, Lance Andersen wrote: >> make/autoconf/lib-bundled.m4 line 220: >> >>> 218: if test "x$USE_EXTERNAL_LIBZ" = "xfalse"; then >>> 219: LIBZ_CFLAGS="$LIBZ_CFLAGS >>> -I$TOPDIR/src/java.base/share/native/libzip/zlib" >>> 220: if test "x$OPENJDK_TARGET_OS"

Re: RFR: 8286122: [macos]: App bundle cannot upload to Mac App Store due to info.plist embedded in java exe

2022-05-12 Thread Magnus Ihse Bursie
(cc:ing build-dev.) On 2022-05-12 00:17, Michael Hall wrote: Is this restricted somehow to Mac App Store applications? Is a warning issued as stripping native commands may break application functionality? Is it not possible for the user to provide their own Info.plist with a different bund

Re: RFR: 8286623: Bundle zlib by default with JDK on macos aarch64

2022-05-12 Thread Magnus Ihse Bursie
On Thu, 12 May 2022 08:43:56 GMT, Jaikiran Pai wrote: > Can I please get a review of this change to the build system which now makes > bundled zlib as the default for macos aarch64 systems? > > We have been running into various intermittent failures on macos aarch64 > systems for several mont

Re: RFR: 8286562: GCC 12 reports some compiler warnings [v4]

2022-05-12 Thread Magnus Ihse Bursie
On Thu, 12 May 2022 01:29:13 GMT, Yasumasa Suenaga wrote: >> Yasumasa Suenaga has updated the pull request incrementally with one >> additional commit since the last revision: >> >> Calculate char offset before realloc() > > Thanks for all to review this PR! I think we should separate this is

Re: RFR: 8286122: [macos]: App bundle cannot upload to Mac App Store due to info.plist embedded in java exe

2022-05-12 Thread Magnus Ihse Bursie
On 2022-05-12 13:17, Michael Hall wrote: I had read this but possibly didn’t grok the issue myself. If I understand correctly now the conflict isn’t within the application but across applications to some other application that has already been added to the Mac App Store that included the comman

Re: RFR: 8286122: [macos]: App bundle cannot upload to Mac App Store due to info.plist embedded in java exe

2022-05-12 Thread Magnus Ihse Bursie
Aren't we embedding this bundle ID in every launcher, so you would need a .template for each possible launcher that could be included in an app? I naively assumed that only the java launcher was needed, since this is about packaging a Java app, so all you'd need is an entry to your main clas

Re: RFR: 8286122: [macos]: App bundle cannot upload to Mac App Store due to info.plist embedded in java exe [v2]

2022-05-12 Thread Magnus Ihse Bursie
On Thu, 12 May 2022 04:15:50 GMT, Alexander Matveev wrote: >> - It is not possible to support native JDK commands such as "java" inside >> Mac App Store bundles due to embedded info.plist. Workarounds suggested in >> JDK-8286122 does not seems to be visible. >> - With proposed fix we will enf

Re: RFR: 8242181: [Linux] Show source information when printing native stack traces in hs_err files [v8]

2022-05-13 Thread Magnus Ihse Bursie
On Fri, 8 Apr 2022 11:11:29 GMT, Christian Hagedorn wrote: >> When printing the native stack trace on Linux (mostly done for hs_err >> files), it only prints the method with its parameters and a relative offset >> in the method: >> >> Stack: [0x7f6e01739000,0x7f6e0183a000], sp=0x

Re: RFR: 8242181: [Linux] Show source information when printing native stack traces in hs_err files [v8]

2022-05-13 Thread Magnus Ihse Bursie
On Fri, 13 May 2022 08:43:35 GMT, Christian Hagedorn wrote: >> I'm googling around for some information about -gdwarf-4 but is mostly >> coming up empty handed. :( I found >> [this](https://www.phoronix.com/scan.php?page=news_item&px=GCC-11-DWARF-5-Possible-Default) >> saying that dwarf-5 bec

Re: RFR: 8286262: Windows: Cleanup deprecation warning suppression

2022-05-16 Thread Magnus Ihse Bursie
On Sun, 15 May 2022 20:50:25 GMT, Kim Barrett wrote: > Please review this cleanup of deprecation warning suppression when building > for Windows. > > This change consists of several parts. > > (1) Remove the global deprecation warning suppression when building HotSpot > for Windows. > > (2) Ad

Re: RFR: 8282322: AArch64: Provide a means to eliminate all STREX family of instructions

2022-05-20 Thread Magnus Ihse Bursie
On Wed, 18 May 2022 19:05:03 GMT, Dmitry Chuyko wrote: > On AArch64 it is sometimes convenient to have LSE atomics right from the > start. Currently they are enabled after feature detection and RR reverse > debugger works incorrectly. > > New build configuration feature 'hardlse' is added. If

Re: RFR: 8284209: Replace remaining usages of 'a the' in source code

2022-05-20 Thread Magnus Ihse Bursie
On Wed, 18 May 2022 14:46:42 GMT, Alexey Ivanov wrote: > Replaces usages of articles that follow each other in all combinations: > a/the, an?/an?, the/the… > > It's the last issue in the series, and it still touches different areas of > the code. Build changes look good. Thanks for the cleanu

RFR: 8287155: Additional make typos

2022-05-23 Thread Magnus Ihse Bursie
Testing ispell + shell magic to locate typos. It worked, but is not scalable to the entire JDK. :-( Keep the fixes for the problems found in the make directory, though. - Commit messages: - 8287155: Additional make typos Changes: https://git.openjdk.java.net/jdk/pull/8837/files W

RFR: 8287174: Remove deprecated configure arguments

2022-05-23 Thread Magnus Ihse Bursie
We have a bunch of configure arguments that has been deprecated for multiple releases. These should be removed. In effect, this will raise an error instead of a warning if these argument is included on the command line for configure. The deprecated arguments stopped having any effect when they w

Integrated: 8287155: Additional make typos

2022-05-23 Thread Magnus Ihse Bursie
On Mon, 23 May 2022 10:04:14 GMT, Magnus Ihse Bursie wrote: > Testing ispell + shell magic to locate typos. It worked, but is not scalable > to the entire JDK. :-( Keep the fixes for the problems found in the make > directory, though. This pull request has now been integrated.

Integrated: 8287174: Remove deprecated configure arguments

2022-05-24 Thread Magnus Ihse Bursie
On Mon, 23 May 2022 17:25:30 GMT, Magnus Ihse Bursie wrote: > We have a bunch of configure arguments that has been deprecated for multiple > releases. These should be removed. In effect, this will raise an error > instead of a warning if these argument is included on the command

Re: RFR: 8287202: GHA: Add macOS aarch64 to the list of default platforms for workflow_dispatch event

2022-05-24 Thread Magnus Ihse Bursie
On Tue, 24 May 2022 06:41:52 GMT, Christoph Langer wrote: > It seems that it was forgotten to add the macOS aarch64 platform to the > default platforms of workflow_dispatch. Let's fix this. Marked as reviewed by ihse (Reviewer). - PR: https://git.openjdk.java.net/jdk/pull/8861

<    2   3   4   5   6   7   8   9   10   11   >