Re: RFR: 8319121: hsdis binutils: speedup building from source
On Mon, 30 Oct 2023 15:41:48 GMT, Robbin Ehn wrote: > Hi all, please consider. > > Tested configure with binutils-src. > > Thanks I think you are correct, I tested on some more machines. On my vf2 dev board (4-core rv64) it do speed up sh configure, from 7:19 to 3:40. I see like 20 instances of cc1 instead 1, a bit to many :) I'll close PR and leave enhancement open! Thanks for having a look! - PR Comment: https://git.openjdk.org/jdk/pull/16421#issuecomment-1786539551
Withdrawn: 8319121: hsdis binutils: speedup building from source
On Mon, 30 Oct 2023 15:41:48 GMT, Robbin Ehn wrote: > Hi all, please consider. > > Tested configure with binutils-src. > > Thanks This pull request has been closed without being integrated. - PR: https://git.openjdk.org/jdk/pull/16421
Re: RFR: JDK-8296240: Augment discussion of test tiers in doc/testing.md [v5]
> Clarify the intention of tier 1 tests. I'll reflow the paragraph and > regenerate the HTML file once the wording is agreed upon. Joe Darcy has updated the pull request incrementally with one additional commit since the last revision: Initial check-in of updated HTML file. - Changes: - all: https://git.openjdk.org/jdk/pull/16384/files - new: https://git.openjdk.org/jdk/pull/16384/files/688e9b67..819d5006 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=16384&range=04 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=16384&range=03-04 Stats: 15 lines in 1 file changed: 8 ins; 0 del; 7 mod Patch: https://git.openjdk.org/jdk/pull/16384.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/16384/head:pull/16384 PR: https://git.openjdk.org/jdk/pull/16384
Re: RFR: JDK-8306980: Generated docs should contain correct Legal Documents [v2]
On Thu, 26 Oct 2023 17:53:12 GMT, Jonathan Gibbons wrote:
>> Please review an update to the way that `javadoc` handles the default legal
>> notices when generating docs.
>>
>> Previously, the default notices were taken from the module's `legal`
>> directory (`$JAVA_HOME/legal/jdk.javadoc`), but in some contexts, these
>> files were either symbolic links, or "descriptive links" -- text files
>> containing the words "Please see ..." -- on platforms that did not support
>> symbolic links. This was set up when using `jlink` to create the image.
>> These "descriptive links" were insufficient and inappropriate when used in a
>> generated docs bundle.
>>
>> The solution is to put a copy of the necessary files into the `jdk.javadoc`
>> module itself, at build time, as resource files, and to copy the files from
>> there instead of the module's `legal` directory.
>>
>> The set of files may vary depending on the kind of build, so care is taken
>> to not hardwire any specific list of names into the code. This means using
>> direct access to the underlying `jrt:` file system in order to determine the
>> set of legal notices that were set up at build time.
>>
>> The main test for legal notices is updated to verify that the words "Please
>> see ..." do not appear in any of the legal notices in a generated docs
>> bundle. There should be no other change to the set of legal notices.
>>
>> Two other tests were affected, because they provided their own minimal file
>> manager for use with `javadoc`, which relied on default methods in the file
>> manager API. These default methods are not sufficiently for handling paths
>> in non-default file systems, such as the `jrt:` file system used to access
>> the resources for the legal notices. The fix is just to override the
>> necessary methods.
>
> Jonathan Gibbons has updated the pull request incrementally with one
> additional commit since the last revision:
>
> Address review feedback
src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/HtmlDoclet.java
line 347:
> 345: case "", "default" -> {
> 346: // use a dummy resource as a stand-in, because we cannot
> get the URL for a resources directory
> 347: var url =
> HtmlDoclet.class.getResource(DocPaths.RESOURCES.resolve(DocPaths.STYLESHEET).getPath());
Have you considered getting the legal notices directory from the parent of
`resources/legal/jquery.md` instead of `resources/stylesheet.css`? Using a
relevant file would help the reader.
-
PR Review Comment: https://git.openjdk.org/jdk/pull/16370#discussion_r1376833446
Re: RFR: JDK-8296240: Augment discussion of test tiers in doc/testing.md [v2]
On 10/29/23 11:21 AM, Alan Bateman wrote: On Sat, 28 Oct 2023 21:03:50 GMT, Joe Darcy wrote: So in terms of a sentence or two of guidance, I think "aim for 10 seconds or less almost all of the time for a tier 1 test" is reasonable in this context. Yes, I think making it an aspiration would be better. In passing, you have "selected libraries in the `java.base` module". It might be better to say core APIs in java.base rather than "selected libraries". - PR Comment: https://git.openjdk.org/jdk/pull/16384#issuecomment-1784188449 As well as aspirational guidelines for tier1 tests to be fast, I have long espoused the view (rule?) that all tests should be able to run without using `-timeoutfactor` on a reasonable contemporary developer machine, with a suggestion that a test should never take for longer than half its declared timeout period. -- Jon
Re: OpenJDK 21 Build on MacOS Sonoma throwing WARNING: Secure coding is automatically enabled
On 10/30/23 10:05, Philip Race wrote: It is possible to use Xcode 12 on macOS14. Our internal build system manages to make this work. Don't ask me for the details, because I don't know them very well. Internally we use macOS 13.x and Xcode 14.3.1 to build JDK 22, and macOS 12.x and Xcode 12.4 to build JDK 21. See https://wiki.openjdk.org/display/Build/Supported+Build+Platforms for a mostly up to date set of build platforms and toolchains. /Erik I think you may have to create a (free) Apple developer a/c to be able to get the older Xcodes. That's step 1. But you are going to have to find a way because currently there is no other solution. At least none I can think of. And no, it is nothing to do with deprecation. -phil. On 10/30/23 7:07 AM, Asif Ikram wrote: Dear Philip Thanks for your response and directions. I guess it is not possible to use Xcode 12.x on MacOS14, because it asks for the latest version of Xcode. I used the OpenJDk20 binary and OpenJDK21 binary to create the build from OpenJDK21+35 source code, but I'm still facing the same problem with my build. Is it MacOS14 and ist AppKit causing the issue? Apple has deprecated some native methods in MacOS14. https://developer.apple.com/documentation/macos-release-notes/appkit-release-notes-for-macos-14 best regards Asif On Sat, Oct 28, 2023 at 1:20 AM Philip Race wrote: This is due you using a newer compiler than the "official" one used by OpenJDK for JDK21 We will have a fix to silence it for JDK 22, but that won't help your JDK 21 build. You'll need to use Xcode 12.x instead of whatever you are using. -phil. On 10/24/23 9:57 AM, Asif Ikram wrote: Dear Team Can you please help me with this? *2023-10-24 12:16:57.027 java[97952:198365] WARNING: Secure coding is automatically enabled for restorable state! However, not on all supported macOS versions of this application. Opt-in to secure coding explicitly by implementing NSApplicationDelegate.applicationSupportsSecureRestorableState:.* I have created OpenJDK 21+35 Build on MacOS 14 Sonoma. I am not able to complete a few AWT tests in JCK21 (JT Harness Runtime). Best regards Asif
Re: RFR: JDK-8313790: [arm32] Specify -marm when building without an ABI profile
On Fri, 4 Aug 2023 16:17:04 GMT, Thomas Stuefe wrote: > See [JDK-8288719](https://bugs.openjdk.org/browse/JDK-8288719) and subsequent > [discussion](https://mail.openjdk.org/pipermail/build-dev/2022-May/034635.html) > back in 2022. > > On Arm, we can generate either arm- or thumb-code (`-marm` or `-mthumb`). > > At the moment, if we don't specify an ABI profile (`--with_abi_profile`) when > configuring the build, we call gcc without `-marm` or `-mthumb`. Then we use > whatever the toolchain defaults too, which is pretty much random (it depends > on how the toolchain itself had been built). That can cause really rare but > tricky problems when combining static assembly and C++ code (See e.g. > JDK-8288719). > > I propose to always specify `-marm` as default, unless an ABI profile is > given, to prevent such errors. > > Thanks to @marchof for testing this. Marked as reviewed by erikj (Reviewer). - PR Review: https://git.openjdk.org/jdk/pull/15162#pullrequestreview-1704801394
Re: RFR: 8319121: hsdis binutils: speedup building from source
On Mon, 30 Oct 2023 15:41:48 GMT, Robbin Ehn wrote: > Hi all, please consider. > > Tested configure with binutils-src. > > Thanks This is a good idea, but to get it to work I think we need to re-order things in `configure.ac`. `BPERF_SETUP_BUILD_JOBS` is currently quite late. `LIB_SETUP_LIBRARIES` (where I assume this is happening) happens long before that. Unless there is some implicit re-ordering happening currently that I'm not aware of. - PR Review: https://git.openjdk.org/jdk/pull/16421#pullrequestreview-1704799218
Re: RFR: JDK-8296240: Augment discussion of test tiers in doc/testing.md [v4]
> Clarify the intention of tier 1 tests. I'll reflow the paragraph and > regenerate the HTML file once the wording is agreed upon. Joe Darcy has updated the pull request incrementally with one additional commit since the last revision: Implement review feedback. - Changes: - all: https://git.openjdk.org/jdk/pull/16384/files - new: https://git.openjdk.org/jdk/pull/16384/files/6a0dac7b..688e9b67 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=16384&range=03 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=16384&range=02-03 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/16384.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/16384/head:pull/16384 PR: https://git.openjdk.org/jdk/pull/16384
Re: RFR: JDK-8296240: Augment discussion of test tiers in doc/testing.md [v2]
On Sun, 29 Oct 2023 18:19:12 GMT, Alan Bateman wrote: > > So in terms of a sentence or two of guidance, I think "aim for 10 seconds > > or less almost all of the time for a tier 1 test" is reasonable in this > > context. > > Yes, I think making it an aspiration would be better. > > In passing, you have "selected libraries in the `java.base` module". It might > be better to say core APIs in java.base rather than "selected libraries". Update to "core". Once the exact wording is agreed to, I'll reflow the affected paragraphs and regenerate the HTML before pushing. - PR Comment: https://git.openjdk.org/jdk/pull/16384#issuecomment-1785709897
Re: OpenJDK 21 Build on MacOS Sonoma throwing WARNING: Secure coding is automatically enabled
It is possible to use Xcode 12 on macOS14. Our internal build system manages to make this work. Don't ask me for the details, because I don't know them very well. I think you may have to create a (free) Apple developer a/c to be able to get the older Xcodes. That's step 1. But you are going to have to find a way because currently there is no other solution. At least none I can think of. And no, it is nothing to do with deprecation. -phil. On 10/30/23 7:07 AM, Asif Ikram wrote: Dear Philip Thanks for your response and directions. I guess it is not possible to use Xcode 12.x on MacOS14, because it asks for the latest version of Xcode. I used the OpenJDk20 binary and OpenJDK21 binary to create the build from OpenJDK21+35 source code, but I'm still facing the same problem with my build. Is it MacOS14 and ist AppKit causing the issue? Apple has deprecated some native methods in MacOS14. https://developer.apple.com/documentation/macos-release-notes/appkit-release-notes-for-macos-14 best regards Asif On Sat, Oct 28, 2023 at 1:20 AM Philip Race wrote: This is due you using a newer compiler than the "official" one used by OpenJDK for JDK21 We will have a fix to silence it for JDK 22, but that won't help your JDK 21 build. You'll need to use Xcode 12.x instead of whatever you are using. -phil. On 10/24/23 9:57 AM, Asif Ikram wrote: Dear Team Can you please help me with this? *2023-10-24 12:16:57.027 java[97952:198365] WARNING: Secure coding is automatically enabled for restorable state! However, not on all supported macOS versions of this application. Opt-in to secure coding explicitly by implementing NSApplicationDelegate.applicationSupportsSecureRestorableState:.* I have created OpenJDK 21+35 Build on MacOS 14 Sonoma. I am not able to complete a few AWT tests in JCK21 (JT Harness Runtime). Best regards Asif
RFR: JDK-8313790: [arm32] Specify -marm when building without an ABI profile
See [JDK-8288719](https://bugs.openjdk.org/browse/JDK-8288719) and subsequent [discussion](https://mail.openjdk.org/pipermail/build-dev/2022-May/034635.html) back in 2022. On Arm, we can generate either arm- or thumb-code (`-marm` or `-mthumb`). At the moment, if we don't specify an ABI profile (`--with_abi_profile`) when configuring the build, we call gcc without `-marm` or `-mthumb`. Then we use whatever the toolchain defaults too, which is pretty much random (it depends on how the toolchain itself had been built). That can cause really rare but tricky problems when combining static assembly and C++ code (See e.g. JDK-8288719). I propose to always specify `-marm` as default, unless an ABI profile is given, to prevent such errors. Thanks to @marchof for testing this. - Commit messages: - Merge branch 'openjdk:master' into JDK-8313790-arm32-Specify-marm-when-building-without-an-ABI-profile - Merge branch 'openjdk:master' into JDK-8313790-arm32-Specify-marm-when-building-without-an-ABI-profile - Merge branch 'openjdk:master' into JDK-8313790-arm32-Specify-marm-when-building-without-an-ABI-profile - Merge branch 'openjdk:master' into JDK-8313790-arm32-Specify-marm-when-building-without-an-ABI-profile - Merge branch 'openjdk:master' into JDK-8313790-arm32-Specify-marm-when-building-without-an-ABI-profile - Merge branch 'openjdk:master' into JDK-8313790-arm32-Specify-marm-when-building-without-an-ABI-profile - start Changes: https://git.openjdk.org/jdk/pull/15162/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=15162&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8313790 Stats: 6 lines in 1 file changed: 6 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/15162.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/15162/head:pull/15162 PR: https://git.openjdk.org/jdk/pull/15162
RFR: 8319121: hsdis binutils: speedup building from source
Hi all, please consider. Tested configure with binutils-src. Thanks - Commit messages: - Use -j Changes: https://git.openjdk.org/jdk/pull/16421/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=16421&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8319121 Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/16421.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/16421/head:pull/16421 PR: https://git.openjdk.org/jdk/pull/16421
Re: RFR: 8317132: Prepare HotSpot for permissive- [v9]
> Prepare HotSpot for the permissive- Visual C++ flag, this change contains all > of the fixes required for HotSpot to compile under the stricter mode > activated when the permissive- flag is passed > > - Reworks code in topLevelUnhandledExceptionFilter for os_windows.cpp to > avoid goto jumping across uninitialized locals > - Adds a CAST_FROM_FN_PTR cast to the return value from ::signal to void, as > they cannot be implicitly converted > - symbolengine.cpp's SimpleBufferWithFallback's templates cannot work with a > raw char (Actual fix under discussion) > - Removed a throw() specification from a mismatched definition in > allocation.cpp Julian Waters has updated the pull request incrementally with one additional commit since the last revision: permissive- positioning flags-cflags.m4 - Changes: - all: https://git.openjdk.org/jdk/pull/15955/files - new: https://git.openjdk.org/jdk/pull/15955/files/331691dd..f99aef3c Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=15955&range=08 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=15955&range=07-08 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/15955.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/15955/head:pull/15955 PR: https://git.openjdk.org/jdk/pull/15955
Re: RFR: 8317132: Prepare HotSpot for permissive- [v8]
On Mon, 30 Oct 2023 15:08:03 GMT, Julian Waters wrote: >> Prepare HotSpot for the permissive- Visual C++ flag, this change contains >> all of the fixes required for HotSpot to compile under the stricter mode >> activated when the permissive- flag is passed >> >> - Reworks code in topLevelUnhandledExceptionFilter for os_windows.cpp to >> avoid goto jumping across uninitialized locals >> - Adds a CAST_FROM_FN_PTR cast to the return value from ::signal to void, as >> they cannot be implicitly converted >> - symbolengine.cpp's SimpleBufferWithFallback's templates cannot work with a >> raw char (Actual fix under discussion) >> - Removed a throw() specification from a mismatched definition in >> allocation.cpp > > Julian Waters has updated the pull request incrementally with one additional > commit since the last revision: > > Change '\0' to 0 in symbolengine.cpp Sorry, re-requesting reviews from all again, as well as permission for including -permissive- for HotSpot here - PR Comment: https://git.openjdk.org/jdk/pull/15955#issuecomment-1785425910
Re: OpenJDK 21 Build on MacOS Sonoma throwing WARNING: Secure coding is automatically enabled
Dear Philip Thanks for your response and directions. I guess it is not possible to use Xcode 12.x on MacOS14, because it asks for the latest version of Xcode. I used the OpenJDk20 binary and OpenJDK21 binary to create the build from OpenJDK21+35 source code, but I'm still facing the same problem with my build. Is it MacOS14 and ist AppKit causing the issue? Apple has deprecated some native methods in MacOS14. https://developer.apple.com/documentation/macos-release-notes/appkit-release-notes-for-macos-14 best regards Asif On Sat, Oct 28, 2023 at 1:20 AM Philip Race wrote: > This is due you using a newer compiler than the "official" one used by > OpenJDK for JDK21 > We will have a fix to silence it for JDK 22, but that won't help your JDK > 21 build. > You'll need to use Xcode 12.x instead of whatever you are using. > > -phil. > > On 10/24/23 9:57 AM, Asif Ikram wrote: > > > Dear Team > > Can you please help me with this? > > > *2023-10-24 12:16:57.027 java[97952:198365] WARNING: Secure coding is > automatically enabled for restorable state! However, not on all supported > macOS versions of this application. Opt-in to secure coding explicitly by > implementing > NSApplicationDelegate.applicationSupportsSecureRestorableState:.* > > > I have created OpenJDK 21+35 Build on MacOS 14 Sonoma. > I am not able to complete a few AWT tests in JCK21 (JT Harness Runtime). > > Best regards > Asif > > >
Re: RFR: 8314488: Compile the JDK as C++17
On Mon, 24 Jul 2023 01:41:16 GMT, Julian Waters wrote: > Implementation of [JEP draft: Compile the JDK as > C++17](https://bugs.openjdk.org/browse/JDK-8310260) Keeping alive - PR Comment: https://git.openjdk.org/jdk/pull/14988#issuecomment-1785145814
Integrated: JDK-8318961: increase javacserver connection timeout values and max retry attempts
On Fri, 27 Oct 2023 10:43:58 GMT, Matthias Baesken wrote: > Increase javacserver connection timeout values and max retry attempts for > better make stability on some slower machines. This pull request has now been integrated. Changeset: b9983c72 Author:Matthias Baesken URL: https://git.openjdk.org/jdk/commit/b9983c72295a31e5f5079bc96c892177fbea3a6e Stats: 4 lines in 1 file changed: 0 ins; 0 del; 4 mod 8318961: increase javacserver connection timeout values and max retry attempts Reviewed-by: clanger, erikj - PR: https://git.openjdk.org/jdk/pull/16397
Re: RFR: JDK-8318961: increase javacserver connection timeout values and max retry attempts [v2]
On Mon, 30 Oct 2023 09:29:05 GMT, Matthias Baesken wrote: >> Increase javacserver connection timeout values and max retry attempts for >> better make stability on some slower machines. > > Matthias Baesken has updated the pull request incrementally with one > additional commit since the last revision: > > Adjust WAIT_BETWEEN_CONNECT_ATTEMPTS Hi Christoph and Erik, thanks for the reviews ! - PR Comment: https://git.openjdk.org/jdk/pull/16397#issuecomment-1785134884
Re: RFR: JDK-8318961: increase javacserver connection timeout values and max retry attempts [v2]
On Mon, 30 Oct 2023 09:29:05 GMT, Matthias Baesken wrote: >> Increase javacserver connection timeout values and max retry attempts for >> better make stability on some slower machines. > > Matthias Baesken has updated the pull request incrementally with one > additional commit since the last revision: > > Adjust WAIT_BETWEEN_CONNECT_ATTEMPTS Marked as reviewed by erikj (Reviewer). - PR Review: https://git.openjdk.org/jdk/pull/16397#pullrequestreview-1704047915
Re: RFR: JDK-8318961: increase javacserver connection timeout values and max retry attempts [v2]
> Increase javacserver connection timeout values and max retry attempts for > better make stability on some slower machines. Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision: Adjust WAIT_BETWEEN_CONNECT_ATTEMPTS - Changes: - all: https://git.openjdk.org/jdk/pull/16397/files - new: https://git.openjdk.org/jdk/pull/16397/files/314ddfbb..a165403f Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=16397&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=16397&range=00-01 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/16397.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/16397/head:pull/16397 PR: https://git.openjdk.org/jdk/pull/16397
Re: RFR: JDK-8318961: increase javacserver connection timeout values and max retry attempts
On Fri, 27 Oct 2023 10:43:58 GMT, Matthias Baesken wrote: > Increase javacserver connection timeout values and max retry attempts for > better make stability on some slower machines. I adjusted the WAIT_BETWEEN_CONNECT_ATTEMPTS; Let's how this works. - PR Comment: https://git.openjdk.org/jdk/pull/16397#issuecomment-1784793547
