Re: RFR: 8287745 jni/nullCaller/NullCallerTest.java fails with "exitValue = 1"

2022-06-07 Thread David Holmes
On Mon, 6 Jun 2022 15:56:47 GMT, Tim Prinzing wrote: > The idea was to reduce duplicate code. Changing to use objects to encapsulate > the up calls got rid of a lot of repeated code and made things simpler and > clearer. Objects are created with the class, method, and signature strings > and

Re: RFR: 8287828: Fix so that one can select jtreg test case by ID from make

2022-06-06 Thread David Holmes
On Sat, 4 Jun 2022 01:51:20 GMT, Leo Korinth wrote: > One can select a testcase by ID when running a jtreg test case directly from > jtreg (using the testcase.java#testID syntax). However, this has not been > possible to do when launching jtreg indirectly from make. > > This fix attempts to

Re: RFR: 8287745 jni/nullCaller/NullCallerTest.java fails with "exitValue = 1"

2022-06-06 Thread David Holmes
On Fri, 3 Jun 2022 07:56:38 GMT, Tim Prinzing wrote: > Fixed JtregNativeJdk.gmk to include c++ libs for NullCallerTest Hi Tim, Sorry but I have to ask why this test was created as a C++ program instead of keeping it as a C program likes it predecessors? No need for C++ libs or special

Re: RFR: JDK-8284858: Start of release updates for JDK 20 [v4]

2022-05-31 Thread David Holmes
On Wed, 1 Jun 2022 03:18:44 GMT, Joe Darcy wrote: >> Time to start getting ready for JDK 20... > > Joe Darcy 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

Re: Integrated: 8286562: GCC 12 reports some compiler warnings

2022-05-27 Thread David Holmes
The new assertion in src/hotspot/share/utilities/globalDefinitions.hpp inline const char* type2name(BasicType t) { assert((uint)t < T_CONFLICT + 1, "invalid type"); return type2name_tab[t]; } is failing with test compiler/jvmci/errors/TestInvalidDebugInfo.java I have filed:

Re: RFR: JDK-8284858: Start of release updates for JDK 20 [v2]

2022-05-27 Thread David Holmes
On Thu, 26 May 2022 23:05:32 GMT, Joe Darcy wrote: >> Time to start getting ready for JDK 20... > > Joe Darcy has updated the pull request incrementally with one additional > commit since the last revision: > > Respond to review feedback. Marked as reviewed by dholmes (Reviewer).

Re: RFR: JDK-8284858: Start of release updates for JDK 20

2022-05-26 Thread David Holmes
On Thu, 14 Apr 2022 05:09:14 GMT, Joe Darcy wrote: > Time to start getting ready for JDK 20... One comment below. I ignored the sym files. Everything else appears okay. Thanks. src/java.base/share/classes/jdk/internal/org/objectweb/asm/Opcodes.java line 312: > 310: int V18 = 0 << 16 |

Re: RFR: 8287174: Remove deprecated configure arguments

2022-05-23 Thread David Holmes
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 line for >

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

2022-05-23 Thread David Holmes
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)

Re: pre-submit tests for github PRs

2022-05-22 Thread David Holmes
On 23/05/2022 8:22 am, Philip Race wrote: Why is it that the vast majority of PRs are recording spurious looking failures of github pre-submit tests ? https://github.com/openjdk/jdk/pulls?q=type%3Apr+is%3Aopen+label%3Arfr There seems to be so much noise in these that I pay no attention to

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

2022-05-17 Thread David Holmes
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)

Re: RFR: 8280844: Epoch shift synchronization point for Compiler threads is inadequate

2022-05-16 Thread David Holmes
On Mon, 16 May 2022 10:17:42 GMT, Markus Grönlund wrote: > Greetings, > > [JDK-8233111](https://bugs.openjdk.java.net/browse/JDK-8233111) attempted to > address artefact tagging for Compiler threads, letting threads run > _thread_in_native to avoid the transition. Unfortunately, that attempt

Re: RFR: 8286744: failure_handler: dmesg command on macos fails to collect data due to permission issues [v2]

2022-05-16 Thread David Holmes
On Mon, 16 May 2022 07:54:09 GMT, Jaikiran Pai wrote: >> Jaikiran Pai has updated the pull request incrementally with one additional >> commit since the last revision: >> >> copyright year > > Thank you Daniel and Lance for the reviews. > > Would anyone from the build team like to provide

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

2022-05-11 Thread David Holmes
On Wed, 11 May 2022 16:00:32 GMT, Maxim Kartashev wrote: >> Matthias Baesken has updated the pull request incrementally with one >> additional commit since the last revision: >> >> adjust API level to Windows 8 for security.cpp and do some cleanup > > This change seem to have made this

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

2022-05-09 Thread David Holmes
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

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

2022-05-06 Thread David Holmes
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 : >>

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

2022-05-04 Thread David Holmes
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 : >>

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

2022-05-03 Thread David Holmes
On Tue, 3 May 2022 07:10:58 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 : >>

Re: RFR: JDK-8285730: unify _WIN32_WINNT settings

2022-04-28 Thread David Holmes
On Wed, 27 Apr 2022 14:57:41 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 : >

Re: RFR: JDK-8285730: unify _WIN32_WINNT settings

2022-04-27 Thread David Holmes
On Wed, 27 Apr 2022 14:57:41 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 : >

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

2022-04-11 Thread David Holmes
On Mon, 11 Apr 2022 21:03:22 GMT, Magnus Ihse Bursie wrote: >> Andrew Leonard has updated the pull request incrementally with one >> additional commit since the last revision: >> >> 8284661: Reproducible assembly builds without relative linking >> >> Signed-off-by: Andrew Leonard > >

Re: RFR: 8282191: Implementation of Foreign Function & Memory API (Preview) [v24]

2022-04-11 Thread David Holmes
On Mon, 11 Apr 2022 12:04:41 GMT, Maurizio Cimadamore wrote: >> src/hotspot/share/prims/scopedMemoryAccess.cpp line 141: >> >>> 139: >>> 140: /* >>> 141: * This function performs a thread-local handshake against all threads >>> running at the time >> >> Nit: thread-local?? > > I was

Re: RFR: 8282191: Implementation of Foreign Function & Memory API (Preview) [v24]

2022-04-11 Thread David Holmes
On Mon, 4 Apr 2022 14:57:30 GMT, Maurizio Cimadamore wrote: >> This PR contains the API and implementation changes for JEP-424 [1]. A more >> detailed description of such changes, to avoid repetitions during the review >> process, is included as a separate comment. >> >> [1] -

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

2022-03-29 Thread David Holmes
On 29/03/2022 7:20 pm, Magnus Ihse Bursie wrote: 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

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

2022-03-28 Thread David Holmes
On Mon, 28 Mar 2022 12:58:20 GMT, Thomas Stuefe 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 54 commits: >> >> - Updating some comments >> - Cleanup loading dwarf file and add summary >> -

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

2022-03-28 Thread David Holmes
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 the context here is that Jai is chasing

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

2022-03-28 Thread David Holmes
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. Cheers, David On 28/03/2022 2:50 pm, Jaikiran Pai wrote: I'm using the following set of commands to build the JDK on my Mac M1 12.2.1

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

2022-03-22 Thread David Holmes
On Tue, 22 Mar 2022 12:08:01 GMT, Fei Yang wrote: >> make/autoconf/libraries.m4 line 152: >> >>> 150: fi >>> 151: >>> 152: # Programs which use C11 or C++11 atomics, like #include , >> >> Use of C++ atomics is not allowed in hotspot code base. See the style guide: >>

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

2022-03-22 Thread David Holmes
On Tue, 22 Mar 2022 11:50:13 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

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

2022-03-21 Thread David Holmes
On Tue, 22 Mar 2022 03:31:16 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

Re: RFR: 8253495: CDS generates non-deterministic output

2022-03-10 Thread David Holmes
On 11/03/2022 4:50 pm, Thomas Stuefe wrote: On Fri, 11 Mar 2022 05:59:00 GMT, David Holmes wrote: Thanks for pointing this out. I ran more tests and found that on certain platforms, there are other structures that have problems with uninitialized gaps. I ended up changing `os::malloc

Re: RFR: 8253495: CDS generates non-deterministic output

2022-03-10 Thread David Holmes
On 11/03/2022 4:40 pm, Ioi Lam wrote: On Fri, 11 Mar 2022 05:59:00 GMT, David Holmes wrote: I ended up changing `os::malloc()` to zero the buffer when running with -Xshare:dump. Hopefully one extra check of `if (DumpSharedSpaces)` doesn't matter too much for regular VM executions because

Re: RFR: 8253495: CDS generates non-deterministic output [v2]

2022-03-10 Thread David Holmes
I can't find this comment in the PR so replying via email ... On 11/03/2022 9:24 am, Ioi Lam wrote: On Wed, 9 Mar 2022 07:47:19 GMT, Thomas Stuefe wrote: Ioi Lam has updated the pull request incrementally with one additional commit since the last revision: Fixed zero build

Re: RFR: 8253495: CDS generates non-deterministic output [v2]

2022-03-10 Thread David Holmes
On Thu, 10 Mar 2022 19:41:03 GMT, Ioi Lam wrote: >> I think he already did. I'm quoting: >> >>> However, the CDS archive also contains a heap dump, which includes Java >>> HashMaps. If I allow those 3 Java threads to start, some HashMaps in the >>> module graph will have unstable ordering. I

Re: RFR: 8253495: CDS generates non-deterministic output [v2]

2022-03-10 Thread David Holmes
On Thu, 10 Mar 2022 12:50:58 GMT, Magnus Ihse Bursie wrote: >> Ioi Lam has updated the pull request incrementally with one additional >> commit since the last revision: >> >> Fixed zero build > > Well, previously we'd get different dumps on different runs. If that was an > issue, surely it

Re: RFR: 8253495: CDS generates non-deterministic output [v2]

2022-03-10 Thread David Holmes
On Thu, 10 Mar 2022 12:11:06 GMT, Magnus Ihse Bursie wrote: >> The "heap dump" aspect of this is not something I'm familiar with, but if >> the threads don't affect the list of classes dumped, they surely must affect >> what is in the heap dump otherwise their execution would not be an issue.

Re: RFR: 8253495: CDS generates non-deterministic output [v2]

2022-03-09 Thread David Holmes
On Wed, 9 Mar 2022 05:10:44 GMT, Ioi Lam wrote: >> This patch makes the result of "java -Xshare:dump" deterministic: >> - Disabled new Java threads from launching. This is harmless. See comments >> in jvm.cpp >> - Fixed a problem in hashtable ordering in heapShared.cpp >> - BasicHashtableEntry

Re: RFR: 8253495: CDS generates non-deterministic output [v2]

2022-03-08 Thread David Holmes
On Wed, 9 Mar 2022 05:10:44 GMT, Ioi Lam wrote: >> This patch makes the result of "java -Xshare:dump" deterministic: >> - Disabled new Java threads from launching. This is harmless. See comments >> in jvm.cpp >> - Fixed a problem in hashtable ordering in heapShared.cpp >> - BasicHashtableEntry

Re: RFR: JDK-8282700: Properly handle several --without options during configure [v2]

2022-03-07 Thread David Holmes
On Mon, 7 Mar 2022 08:07:30 GMT, Julian Waters wrote: >> Some of the --without options are not properly handled and will crash when >> processed (For example, --without-version-string), in other cases the >> --without-* option will actually silently produce incorrect results instead >> of

Re: RFR: 8282657: Code cleanup: removing double semicolons at the end of lines

2022-03-04 Thread David Holmes
On Fri, 28 Jan 2022 14:39:31 GMT, Matteo Baccan wrote: > Hi > > I have reviewed the code for removing double semicolons at the end of lines > > all the best > matteo I eyeballed the diff file and all seems okay. Thanks, David - Marked as reviewed by dholmes (Reviewer). PR:

Re: Windows confusing object file names for other file types

2022-03-03 Thread David Holmes
On 3/03/2022 11:29 pm, Julian Waters wrote: Windows seems to commonly confuse object file names that are created during the build process I don't understand what you mean by that, please elaborate. Thanks, David , despite .obj being the normal file format for object files on it (Weirdly

Re: RFR: JDK-8282532: Allow explicitly setting build platform alongside --openjdk-target [v7]

2022-03-03 Thread David Holmes
On Thu, 3 Mar 2022 16:48:40 GMT, Julian Waters wrote: >> Currently the only other option for manually configuring the build platform >> while cross compiling are devkits, which don't work on certain systems and >> are also more focused on differentiating the build and target compilers >>

Re: RFR: 8277204: Implement PAC-RET branch protection on Linux/AArch64 [v25]

2022-02-25 Thread David Holmes
On Thu, 24 Feb 2022 10:52:00 GMT, Alan Hayward wrote: >> Alan Hayward has updated the pull request with a new target base due to a >> merge or a rebase. The pull request now contains 34 commits: >> >> - Merge master >> - Merge master >> - Merge master >> - Error on

Re: RFR: 8281525: Enable Zc:strictStrings flag in Visual Studio build

2022-02-22 Thread David Holmes
On Mon, 21 Feb 2022 19:55:14 GMT, Daniel Jeliński wrote: > Please review this PR that enables > [Zc:strictStrings](https://docs.microsoft.com/en-us/cpp/build/reference/zc-strictstrings-disable-string-literal-type-conversion?view=msvc-170) > compiler flag, which makes assigning a string literal

Re: macro expansion producing 'defined' has undefined behavior

2022-02-17 Thread David Holmes
Hi Simmias, On 14/02/2022 1:24 pm, 殷玉婷 wrote: Hi, When I ran make images in my local computer to compile the openjdk9u by guideline <>, I encountered the following problems: 9u is not expected to be built by recent Xcode, it was a much older release (not sure if anyone is actually updating

Re: RFR: 8277204: Implementation of JEP 8264130: PAC-RET protection for Linux/AArch64 [v14]

2022-02-02 Thread David Holmes
On Wed, 2 Feb 2022 10:18:38 GMT, Andrew Haley wrote: >> And this change will keep ROP protection enabled if we fall into the "this >> VM was built without ROP-protection support.". In that case we'll be >> protecting generated code, but the VM itself won't be protected. This will >> run

Re: Segfault when building openjdk13 with openjdk12

2022-02-01 Thread David Holmes
On 2/02/2022 3:53 pm, Abigail G wrote: On Wed, 2022-02-02 at 15:48 +1000, David Holmes wrote: Hi Abigail, On 2/02/2022 3:01 pm, Abigail G wrote: Hello, I'm working on packaging several openjdk versions for Void Linux. When I build jdk13 with jdk12 as the boot jdk, I get a segfault very soon

Re: Segfault when building openjdk13 with openjdk12

2022-02-01 Thread David Holmes
Hi Abigail, On 2/02/2022 3:01 pm, Abigail G wrote: Hello, I'm working on packaging several openjdk versions for Void Linux. When I build jdk13 with jdk12 as the boot jdk, I get a segfault very soon into the build. I am not a java developer, so I'm not quite sure what to make of the log,

Re: RFR: 8277204: Implementation of JEP 8264130: PAC-RET protection for Linux/AArch64 [v14]

2022-02-01 Thread David Holmes
On Tue, 1 Feb 2022 11:05:46 GMT, Alan Hayward wrote: >> src/hotspot/cpu/aarch64/vm_version_aarch64.cpp line 429: >> >>> 427: #else >>> 428: warning("UseROPProtection specified, but not supported in the >>> VM."); >>> 429: #endif >> >> If we issue these warnings should `_rop_protection`

Re: RFR: 8277204: Implementation of JEP 8264130: PAC-RET protection for Linux/AArch64 [v14]

2022-01-31 Thread David Holmes
On Mon, 24 Jan 2022 15:56:06 GMT, Alan Hayward wrote: >> PAC is an optional feature in AArch64 8.3 and is compulsory in v9. One >> of its uses is to protect against ROP based attacks. This is done by >> signing the Link Register whenever it is stored on the stack, and >> authenticating the value

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

2022-01-31 Thread David Holmes
Hi Christian, Sorry for the delay in coming back to this, I wanted to see what other feedback arose. On 25/01/2022 7:43 pm, Christian Hagedorn wrote: Hi David This will be really useful - thank you. :) I'm glad to hear that! :-) Thanks for your overall comments! All build file changes

Re: RFR: 8280916: Simplify HotSpot Style Guide editorial changes

2022-01-30 Thread David Holmes
On Sun, 30 Jan 2022 00:39:20 GMT, Kim Barrett wrote: > Please review this change to the HotSpot Style Guide change process. > > The current process involves gathering consensus among the HotSpot Group > Members. That's fine for changes of substance. But it seems overly weighty > for editorial

Re: RFR: 8203290: [PPC64, s390] Check functionality of JDK-8199712 (Flight Recorder) [v15]

2022-01-27 Thread David Holmes
On 27/01/2022 9:01 pm, Goetz Lindenmaier wrote: On Mon, 24 Jan 2022 22:23:33 GMT, Tyler Steele wrote: Just in time for the holidays I have completed an implementation of the JFR functionality for AIX. As a side note, this is my first submission to OpenJDK  ### Implementation notes and

Re: RFR: 8203290: [PPC64, s390] Check functionality of JDK-8199712 (Flight Recorder) [v15]

2022-01-26 Thread David Holmes
On 27/01/2022 10:19 am, Tyler Steele wrote: On Tue, 25 Jan 2022 06:10:19 GMT, Thomas Stuefe wrote: Tyler Steele has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains two commits: - Merge branch 'master' into JDK-8203290 -

Re: RFR: 8203290: [PPC64, s390] Check functionality of JDK-8199712 (Flight Recorder) [v15]

2022-01-25 Thread David Holmes
On 25/01/2022 7:14 pm, Thomas Stuefe wrote: src/hotspot/os/aix/libperfstat_aix.cpp line 2: 1: /* 2: * Copyright (c) 2022, 2022, Oracle and/or its affiliates. All rights reserved. Is there a reason for this copyright addition? Just FYI that is an invalid copyright line for Oracle. There

Re: RFR: 8278753: Runtime crashes with access violation during JNI_CreateJavaVM call

2022-01-24 Thread David Holmes
On Tue, 25 Jan 2022 00:20:19 GMT, Yumin Qi wrote: > Please review, > When jlink with --compress=2, zip is used to compress the files while doing > copy. The user case failed to load zip.dll, since zip.dll is not set in PATH. > This failure is after we get NULL from

Re: RFR: 8278753: Runtime crashes with access violation during JNI_CreateJavaVM call

2022-01-24 Thread David Holmes
On Tue, 25 Jan 2022 00:20:19 GMT, Yumin Qi wrote: > Please review, > When jlink with --compress=2, zip is used to compress the files while doing > copy. The user case failed to load zip.dll, since zip.dll is not set in PATH. > This failure is after we get NULL from

Re: RFR: 8278753: Runtime crashes with access violation during JNI_CreateJavaVM call

2022-01-24 Thread David Holmes
On Tue, 25 Jan 2022 00:20:19 GMT, Yumin Qi wrote: > Please review, > When jlink with --compress=2, zip is used to compress the files while doing > copy. The user case failed to load zip.dll, since zip.dll is not set in PATH. > This failure is after we get NULL from

Re: RFR: 8280182: HotSpot Style Guide has stale link to chromium style guide

2022-01-19 Thread David Holmes
On Tue, 18 Jan 2022 23:09:12 GMT, Liam Miller-Cushon wrote: > Update links to the chromium style guide in the HotSpot Style Guide. Looks good. Thanks for noticing the problem and fixing it. David - Marked as reviewed by dholmes (Reviewer). PR:

Re: Configuration Error in JDK Build Java 8 (JDK8u) for VS

2022-01-17 Thread David Holmes
ements Microsoft Visual Studio I cloned the Git Repo for jdk8u, master branch. Ken On Sunday, January 16, 2022, 10:35:53 PM CST, David Holmes wrote: Hi Ken, On 13/01/2022 9:52 am, Ken Taylor wrote: > I am trying to build JDK 8 from the jdk8u repo, master branch.Project was forked a

Re: RFR: 8203290: [PPC64, s390] Check functionality of JDK-8199712 (Flight Recorder) [v8]

2022-01-16 Thread David Holmes
On 15/01/2022 2:13 am, Tyler Steele wrote: To follow up on an item mentioned above so that it is documented here: I reviewed the functionality from `src/hotspot/os/aix/libperfstat_aix` and found it didn't fit well with the needs of this pr. If it were extended in the future to include the

Re: Configuration Error in JDK Build Java 8 (JDK8u) for VS

2022-01-16 Thread David Holmes
Hi Ken, On 13/01/2022 9:52 am, Ken Taylor wrote: I am trying to build JDK 8 from the jdk8u repo, master branch.Project was forked and cloned into a Windows 10 VM.Building in Cygwin. It appears that the change to support VS 2019 has not been checked in.

Re: Need OpenJDK to be used on PowerPC for our products.

2022-01-06 Thread David Holmes
On 7/01/2022 5:21 am, tim.b...@oracle.com wrote: Forwarded Message Subject: RE: Need OpenJDK to be used on PowerPC for our products. Date: Thu, 6 Jan 2022 19:16:10 + From: Dipendu Ghosh To: mailman-owner Hi, I am an Engineer from Keysight Technologies.

Re: RFR: 8203290: [PPC64, s390] Check functionality of JDK-8199712 (Flight Recorder)

2021-12-21 Thread David Holmes
On Wed, 22 Dec 2021 02:59:43 GMT, Erik Gahlin wrote: >> Just in time for the holidays I have completed an implementation of the JFR >> functionality for AIX. As a side note, this is my first submission to >> OpenJDK  >> >> ### Implementation notes and alternatives considered >> >> After

Re: [jdk18] RFR: JDK-8278967 rmiregistry fails to start because SecurityManager is disabled

2021-12-21 Thread David Holmes
On Sun, 19 Dec 2021 07:37:19 GMT, Alan Bateman wrote: >> Enable the security manager in rmiregistry's launcher arguments. > > As things stand, `rmiregsitry -J-Djava.security.manager` and `rmiregistry > -J-Djava.security.manager=allow` are equivalent because rmiregistry sets the > default SM.

Re: [jdk18] RFR: JDK-8278967 rmiregistry fails to start because SecurityManager is disabled

2021-12-18 Thread David Holmes
On Fri, 17 Dec 2021 20:01:27 GMT, Stuart Marks wrote: > Enable the security manager in rmiregistry's launcher arguments. My concern is that having the SM installed during part of VM initialization could lead to different behaviour compared to installing the SM after that. This may be a small

Re: [jdk18] RFR: JDK-8278967 rmiregistry fails to start because SecurityManager is disabled

2021-12-17 Thread David Holmes
On Fri, 17 Dec 2021 20:01:27 GMT, Stuart Marks wrote: > Enable the security manager in rmiregistry's launcher arguments. Hi Stuart, I think specifying "allow" would be the behaviour preserving change here. That avoids any risk that enabling the SM earlier changes some behaviour during VM

Re: RFR: 8278275: Initial nroff manpage generation for JDK 19

2021-12-13 Thread David Holmes
On Mon, 13 Dec 2021 05:51:37 GMT, David Holmes wrote: > Trivial update to change the version to 19-ea, and update the single > reference to the "current release". > > Content changes for 19 will follow. > > Thanks, > David Thanks for the reviews Erik, Jon and

Integrated: 8278275: Initial nroff manpage generation for JDK 19

2021-12-13 Thread David Holmes
On Mon, 13 Dec 2021 05:51:37 GMT, David Holmes wrote: > Trivial update to change the version to 19-ea, and update the single > reference to the "current release". > > Content changes for 19 will follow. > > Thanks, > David This pull request has now been i

Re: RFR: 8278275: Initial nroff manpage generation for JDK 19

2021-12-12 Thread David Holmes
On Mon, 13 Dec 2021 05:51:37 GMT, David Holmes wrote: > Trivial update to change the version to 19-ea, and update the single > reference to the "current release". > > Content changes for 19 will follow. > > Thanks, > David This "mechanical" update is

RFR: 8278275: Initial nroff manpage generation for JDK 19

2021-12-12 Thread David Holmes
Trivial update to change the version to 19-ea, and update the single reference to the "current release". Content changes for 19 will follow. Thanks, David - Commit messages: - 8278275:Initial nroff manpage generation for JDK 19 Changes:

Re: RFR: 8251400: Fix incorrect addition of library to test in JDK-8237858

2021-12-02 Thread David Holmes
On Thu, 2 Dec 2021 22:45:37 GMT, Magnus Ihse Bursie wrote: > In JDK-8237858, -pthread was added to all native tests, instead of the one > single test that needed it. In the meantime, two new tests with pthread > dependencies has crept in unnoticed due to this. Looks good. I don't think

Re: RFR: 8277204: Implementation of JEP 8264130: PAC-RET protection for Linux/AArch64 [v7]

2021-12-02 Thread David Holmes
On Thu, 2 Dec 2021 09:16:59 GMT, Alan Hayward wrote: > @dholmes-ora > > Fixed flags based on comments on the CSR: Flag updates look good - thanks. - PR: https://git.openjdk.java.net/jdk/pull/6334

Re: RFR: JDK-8273146: Start of release updates for JDK 19 [v3]

2021-11-23 Thread David Holmes
On Tue, 23 Nov 2021 19:23:40 GMT, Joe Darcy wrote: >> The time to get JDK 19 underway draws nigh, please review this usual set of >> start-of-release updates, including CSRs for the javac and javax.lang.model >> updates: >> >> JDK-8277512: Add SourceVersion.RELEASE_19 >>

Re: RFR: JDK-8273146: Start of release updates for JDK 19 [v2]

2021-11-21 Thread David Holmes
On Mon, 22 Nov 2021 04:30:38 GMT, Joe Darcy wrote: >> The time to get JDK 19 underway draws nigh, please review this usual set of >> start-of-release updates, including CSRs for the javac and javax.lang.model >> updates: >> >> JDK-8277512: Add SourceVersion.RELEASE_19 >>

Re: RFR: JDK-8273146: Start of release updates for JDK 19

2021-11-21 Thread David Holmes
On Mon, 22 Nov 2021 03:15:51 GMT, Joe Darcy wrote: > The time to get JDK 19 underway draws nigh, please review this usual set of > start-of-release updates, including CSRs for the javac and javax.lang.model > updates: > > JDK-8277512: Add SourceVersion.RELEASE_19 >

Re: RFR: JDK-8276422 Add command-line option to disable finalization

2021-11-17 Thread David Holmes
On Thu, 18 Nov 2021 07:16:56 GMT, Kim Barrett wrote: > There is nothing here to make the various GCs take advantage of finalization > being disabled. Is the plan to leave that to followup changes? @kimbarrett I provided the basic VM parts here. I'm not aware of what specifically a GC might

Re: RFR: JDK-8276422 Add command-line option to disable finalization

2021-11-17 Thread David Holmes
On Thu, 18 Nov 2021 07:44:05 GMT, Aleksey Shipilev wrote: >> @shipilev not sure what you mean by "a flag on the Java side". The Java >> code just queries the VM for the finalization enabled/disabled state and >> uses that to control things. > > Yeah, "flag" is `Holder.ENABLED` here. I mean,

Re: RFR: JDK-8276422 Add command-line option to disable finalization

2021-11-17 Thread David Holmes
On Thu, 18 Nov 2021 07:27:30 GMT, Aleksey Shipilev wrote: >> @stuart-marks not sure I see how anything is different here compared to the >> existing logic. The `Finalizer` class is explicitly initialized quite early >> in the init process, but if a preceding class's initialization created an

Re: RFR: JDK-8276422 Add command-line option to disable finalization

2021-11-17 Thread David Holmes
On Thu, 18 Nov 2021 05:20:02 GMT, Stuart Marks wrote: >> src/java.base/share/classes/java/lang/ref/Finalizer.java line 195: >> >>> 193: >>> 194: static { >>> 195: if (Holder.ENABLED) { >> >> Hello Stuart, >> My understanding of the the lazy `Holder` is that it's there to delay the

Re: RFR: JDK-8276422 Add command-line option to disable finalization

2021-11-17 Thread David Holmes
On Thu, 18 Nov 2021 01:34:36 GMT, Stuart Marks wrote: > Pretty much what it says. The new option controls a static member in > InstanceKlass that's consulted to determine whether the finalization > machinery is activated for instances when a class is loaded. A new native > method is added so

Re: RFR: 8277012: Use blessed modifier order in src/utils

2021-11-11 Thread David Holmes
On Thu, 11 Nov 2021 14:32:18 GMT, Magnus Ihse Bursie wrote: > I ran bin/blessed-modifier-order.sh on source code in src/utils. This scripts > verifies that modifiers are in the "blessed" order, and fixes it otherwise. I > have manually checked the changes made by the script to make sure they

Re: RFR: 8275872: Sync J2DBench run and analyze Makefile targets with build.xml [v2]

2021-10-26 Thread David Holmes
On Tue, 26 Oct 2021 11:13:19 GMT, Jiří Vaněk wrote: >> Jiří Vaněk has refreshed the contents of this pull request, and previous >> commits have been removed. The incremental views will show differences >> compared to the previous content of the PR. > > Attmept done. Looks like the summary is

Re: RFR: 8275874: [JVMCI] use volatile accessors for all unaligned reads in c2v_readFieldValue

2021-10-25 Thread David Holmes
On Mon, 25 Oct 2021 14:33:27 GMT, Doug Simon wrote: > [JDK-8275645](https://bugs.openjdk.java.net/browse/JDK-8275645) resulted in > loosing single-copy atomicity for reads in `c2v_readFieldValue`. This PR > fixes that by using `_field_acquire` accessors for all aligned reads > and only using

Re: RFR: 8248584: Enable CHECK_UNHANDLED_OOPS for Windows fastdebug builds

2021-10-19 Thread David Holmes
On Tue, 19 Oct 2021 19:21:24 GMT, Harold Seigel wrote: > Please review this small change to enable CHECK_UNHANDLED_OOPs for Windows > fastdebug builds. The change was tested by running Mach5 tiers 1-6 on > Windows-x64-debug. > > Thanks, Harold Seems fine to me. Thanks, David -

Re: RFR: 8275063: Implementation of Foreign Function & Memory API (Second incubator) [v6]

2021-10-18 Thread David Holmes
On Sat, 16 Oct 2021 11:11:59 GMT, Maurizio Cimadamore wrote: >> This PR contains the API and implementation changes for JEP-419 [1]. A more >> detailed description of such changes, to avoid repetitions during the review >> process, is included as a separate comment. >> >> [1] -

Re: Unable to build Client/Server variant for OpenJDK-11 on ARMv7-A

2021-10-13 Thread David Holmes
linked, as the system's glibc I'm using (2.18) is also too outdated to run those. -------- *From:* David Holmes *Sent:* Sunday, October 10, 2021 6:22 PM *To:* Aleksey Shipilev ; John Cummings ; build-dev@openjdk.java.net *Su

Re: RFR: 8275008: gtest build failure due to stringop-overflow warning with gcc11

2021-10-10 Thread David Holmes
On Sun, 10 Oct 2021 13:05:40 GMT, Jie Fu wrote: > Hi all, > > gtest build fails due to stringop-overflow warning with gcc11. > > This is because gcc11 seems to be smart enough to detect the following > stringop-overflow at test/hotspot/gtest/memory/test_guardedMemory.cpp:125:11. > > * For

Re: Unable to build Client/Server variant for OpenJDK-11 on ARMv7-A

2021-10-10 Thread David Holmes
On 9/10/2021 3:58 pm, Aleksey Shipilev wrote: Hi, This does not look a build issue per se, but rather a Hotspot bug. The SIGILL in ThreadGroup.add looks to me like an issue with atomic operations as that is the first synchronized method that gets executed during VM initialization. David

Re: RFR: 8275008: gtest build failure due to stringop-overflow warning with gcc11

2021-10-10 Thread David Holmes
On Sun, 10 Oct 2021 13:05:40 GMT, Jie Fu wrote: > Hi all, > > gtest build fails due to stringop-overflow warning with gcc11. > > This is because gcc11 seems to be smart enough to detect the following > stringop-overflow at test/hotspot/gtest/memory/test_guardedMemory.cpp:125:11. > > * For

Re: RFR: 8274083: Update testing docs to mention tiered testing [v5]

2021-09-23 Thread David Holmes
On Thu, 23 Sep 2021 12:53:23 GMT, Aleksey Shipilev wrote: >> Now that OpenJDK has more or less complete `tier{1,2,3,4}` definitions, >> let's mention them in `testing.md`. >> >> Current patch is my braindump, I am open for suggestions :) > > Aleksey Shipilev has updated the pull request

Re: RFR: 8274083: Update testing docs to mention tiered testing [v3]

2021-09-23 Thread David Holmes
On 23/09/2021 8:33 pm, Thomas Stuefe wrote: On Thu, 23 Sep 2021 09:19:42 GMT, Aleksey Shipilev wrote: Now that OpenJDK has more or less complete `tier{1,2,3,4}` definitions, let's mention them in `testing.md`. Current patch is my braindump, I am open for suggestions :) Aleksey Shipilev

Re: RFR: 8274169: HotSpot Style Guide has stale link to chromium style guide

2021-09-23 Thread David Holmes
On 23/09/2021 8:53 pm, Magnus Ihse Bursie wrote: On Thu, 23 Sep 2021 02:56:05 GMT, David Holmes wrote: Update links to the chromium style guide in the HotSpot Style Guide. Update looks good and trivial. Aside: no idea why changes to these files mapped to build-dev ?? Thanks, David

Re: RFR: 8274083: Update testing docs to mention tiered testing [v2]

2021-09-22 Thread David Holmes
On Wed, 22 Sep 2021 12:28:18 GMT, Aleksey Shipilev wrote: >> Now that OpenJDK has more or less complete `tier{1,2,3,4}` definitions, >> let's mention them in `testing.md`. >> >> Current patch is my braindump, I am open for suggestions :) > > Aleksey Shipilev has updated the pull request

Re: RFR: 8274169: HotSpot Style Guide has stale link to chromium style guide

2021-09-22 Thread David Holmes
On Wed, 22 Sep 2021 20:48:11 GMT, Liam Miller-Cushon wrote: > Update links to the chromium style guide in the HotSpot Style Guide. Update looks good and trivial. Aside: no idea why changes to these files mapped to build-dev ?? Thanks, David - Marked as reviewed by dholmes

Re: RFR: 8274083: Update testing docs to mention tiered testing

2021-09-21 Thread David Holmes
On Tue, 21 Sep 2021 16:06:28 GMT, Aleksey Shipilev wrote: >> doc/testing.html line 77: >> >>> 75: tier1: This test group is the first line of defense >>> against bugs. Multiple developers run these tests every day. Normally, at >>> least this tier is ran before integration. Because of the

Re: RFR: 8273801: Handle VMTYPE for "core" VM variant

2021-09-21 Thread David Holmes
On 20/09/2021 9:43 pm, Magnus Ihse Bursie wrote: On Thu, 16 Sep 2021 12:02:38 GMT, David Holmes wrote: Building with --with-jvm-variants=core currently produces a binary that replies an odd version: $ build/linux-x86_64-core-fastdebug/images/jdk/bin/java -version openjdk version &qu

Re: RFR: 8273801: Handle VMTYPE for "core" VM variant

2021-09-16 Thread David Holmes
On Wed, 15 Sep 2021 09:55:22 GMT, Aleksey Shipilev wrote: > Building with --with-jvm-variants=core currently produces a binary that > replies an odd version: > > > $ build/linux-x86_64-core-fastdebug/images/jdk/bin/java -version > openjdk version "18-internal" 2022-03-15 > OpenJDK Runtime

Re: RFR: 8273801: Handle VMTYPE for "core" VM variant

2021-09-15 Thread David Holmes
On 15/09/2021 11:34 pm, Aleksey Shipilev wrote: On Wed, 15 Sep 2021 12:45:51 GMT, David Holmes wrote: But perhaps we should be looking to remove "core" going forward? Yes, we should consider it. @magicus [told me](https://github.com/openjdk/jdk/pull/5440#discussion_

Re: RFR: 8273797: Stop impersonating "server" VM in all VM variants

2021-09-15 Thread David Holmes
On Wed, 15 Sep 2021 10:02:19 GMT, Aleksey Shipilev wrote: > As the follow-up for Zero-specific JDK-8273494, we might want to clean up > build system logic for all VM variants: stop impersonating "server" VMs for > all of them. This basically leaves "core" and "custom" variants to be handled >

  1   2   3   4   5   6   7   8   9   10   >