Re: RFR: 8252582: HotSpot Style Guide should permit variable templates

On Fri, 12 Sep 2025 01:13:25 GMT, Kim Barrett wrote: > Please review this change to the HotSpot Style Guide to permit the use of > variable templates. This is a C++14 feature that, while fairly simple, didn't > get into the initial permitted for HotSpot list because I just didn't get to > it and

Re: Mixture of product and fastdebug builds in GHA

Hi Matthias, On 11/09/2025 7:09 pm, Baesken, Matthias wrote: So does that mean, that we build all GHA builds with debug level release/product and none with fastdebug ? If so, could we maybe in future use some mixture, like most product but a few e.g. one on Linux one on macOS fastdebug  ?

Re: RFR: 8361950: Update to use jtreg 8 [v4]

On Thu, 4 Sep 2025 22:01:57 GMT, Christian Stein wrote: >> Please review the change to update to using jtreg 8. >> >> The primary change is to the `jib-profiles.js` file, which specifies the >> version of jtreg to use, for those systems that rely on this file. In >> addition, the requiredVersi

Integrated: 8367035: [BACKOUT] Protect ExecuteWithLog from running with redirection without a subshell

On Sun, 7 Sep 2025 20:08:49 GMT, David Holmes wrote: > Revert "8233115: Protect ExecuteWithLog from running with redirection without > a subshell" > > This reverts commit 124fcf1d9abb6cafe34637ba357617c7c7be56c8. > > Thanks This pull request has now been inte

Re: RFR: 8367035: [BACKOUT] Protect ExecuteWithLog from running with redirection without a subshell

On Sun, 7 Sep 2025 20:17:30 GMT, Kim Barrett wrote: >> Revert "8233115: Protect ExecuteWithLog from running with redirection >> without a subshell" >> >> This reverts commit 124fcf1d9abb6cafe34637ba357617c7c7be56c8. >> >> Thanks > > Looks good. Thanks @kimbarrett ! - PR Comment:

RFR: 8367035: [BACKOUT] Protect ExecuteWithLog from running with redirection without a subshell

Revert "8233115: Protect ExecuteWithLog from running with redirection without a subshell" This reverts commit 124fcf1d9abb6cafe34637ba357617c7c7be56c8. Thanks - Commit messages: - Revert "8233115: Protect ExecuteWithLog from running with redirection without a subshell" Changes:

Integrated: 8366121: Hotspot Style Guide should document conventions for lock-free code

On Tue, 26 Aug 2025 00:26:59 GMT, David Holmes wrote: > This is a topic that we, at Oracle, have discussed numerous times over the > years and we have some simple guidelines that never get written down properly > and which we/I tend to forget and then can't locate. To remed

Re: RFR: 8366121: Hotspot Style Guide should document conventions for lock-free code

On Thu, 28 Aug 2025 14:31:20 GMT, Vladimir Kozlov wrote: >> This is a topic that we, at Oracle, have discussed numerous times over the >> years and we have some simple guidelines that never get written down >> properly and which we/I tend to forget and then can't locate. To remedy that >> I wo

Re: RFR: 8345810: Custom launchers must be linked with pthread to avoid dynamic linker issues [v2]

On Thu, 28 Aug 2025 15:10:03 GMT, Aleksey Shipilev wrote: >> See the bug for more investigation. >> >> The symptom of the problem is apparent `SIGSEGV` in `dlerror`. We were able >> to debug it to older glibc issue, which makes `dlerror` not thread-safe when >> pthreads are not yet loaded. Thi

Re: RFR: 8345810: Custom launchers must be linked with pthread to avoid dynamic linker issues

On Thu, 28 Aug 2025 07:43:19 GMT, Aleksey Shipilev wrote: > See the bug for more investigation. > > The symptom of the problem is apparent `SIGSEGV` in `dlerror`. We were able > to debug it to older glibc issue, which makes `dlerror` not thread-safe when > pthreads are not yet loaded. This bug

Re: RFR: 8366121: Hotspot Style Guide should document conventions for lock-free code

On Tue, 26 Aug 2025 00:26:59 GMT, David Holmes wrote: > This is a topic that we, at Oracle, have discussed numerous times over the > years and we have some simple guidelines that never get written down properly > and which we/I tend to forget and then can't locate. To remed

Re: RFR: 8314488: Compiling the JDK with C++17 [v4]

On Mon, 25 Aug 2025 23:31:03 GMT, Kim Barrett wrote: >> Please review this change to use C++17 for building C++ parts of the JDK. In >> particular this affects HotSpot. This change also includes an update to the >> HotSpot Style Guide regarding C++17 features and their use in HotSpot code. >> >>

RFR: 8366121: Hotspot Style Guide should document conventions for lock-free code

This is a topic that we, at Oracle, have discussed numerous times over the years and we have some simple guidelines that never get written down properly and which we/I tend to forget and then can't locate. To remedy that I would like to capture a few very simple style rules that exist for docume

Re: RFR: 8314488: Compiling the JDK with C++17 [v2]

On Fri, 22 Aug 2025 22:18:46 GMT, Kim Barrett wrote: >> Please review this change to use C++17 for building C++ parts of the JDK. In >> particular this affects HotSpot. This change also includes an update to the >> HotSpot Style Guide regarding C++17 features and their use in HotSpot code. >> >>

Re: RFR: 8314488: Compiling the JDK with C++17 [v2]

On Fri, 22 Aug 2025 22:18:46 GMT, Kim Barrett wrote: >> Please review this change to use C++17 for building C++ parts of the JDK. In >> particular this affects HotSpot. This change also includes an update to the >> HotSpot Style Guide regarding C++17 features and their use in HotSpot code. >> >>

Re: RFR: 8260555: Change the default TIMEOUT_FACTOR from 4 to 1 [v5]

On Fri, 22 Aug 2025 15:41:21 GMT, Albert Mingkun Yang wrote: >> Leo Korinth has updated the pull request incrementally with one additional >> commit since the last revision: >> >> update testing.md, remove makefile link, fix bad text > > test/hotspot/jtreg/compiler/tiered/Level2RecompilationT

Re: RFR: 8260555: Change the default TIMEOUT_FACTOR from 4 to 1 [v5]

On Fri, 22 Aug 2025 05:51:38 GMT, Phil Race wrote: >> Leo Korinth has updated the pull request incrementally with one additional >> commit since the last revision: >> >> update testing.md, remove makefile link, fix bad text > > test/jdk/javax/sound/sampled/Clip/AudioContentHandlers.java line

Re: RFR: 8260555: Change the default TIMEOUT_FACTOR from 4 to 1 [v4]

On Wed, 20 Aug 2025 15:21:39 GMT, Magnus Ihse Bursie wrote: > I realize that this is highly hardware dependent, but test times tend to be > Pareto distributed, so a very quick test maybe takes 1 second on fast > machines and 10 on slow, @magicus unfortunately that is often not the case in pra

Re: RFR: 8260555: Change the default TIMEOUT_FACTOR from 4 to 1 [v3]

On Tue, 19 Aug 2025 06:38:01 GMT, SendaoYan wrote: >> No change should be made to any explicit setting of the timeoutFactor in >> general as that could cause mass timeouts to occur (old default timeout = >> 120 * 10 = 1200 but new default = 120 * 2.5 = 300!). >> >> However I see the concern o

Re: RFR: 8260555: Change the default TIMEOUT_FACTOR from 4 to 1 [v3]

On Tue, 19 Aug 2025 05:23:15 GMT, David Holmes wrote: >> Take test >> test/hotspot/jtreg/compiler/arraycopy/stress/TestStressArrayCopy.java as >> example. >> If there is a bug in jvm with -Xcomp option which will cause this test run >> time outed. Before

Re: RFR: 8260555: Change the default TIMEOUT_FACTOR from 4 to 1 [v4]

On Mon, 18 Aug 2025 16:34:21 GMT, Leo Korinth wrote: >> This changes the timeout factor from 4 to 1. Most of the changes add >> timeouts to individual test cases so that I am able to run them with a >> timeout factor of 0.7 (some margin to the checked in factor of one) >> >> In addition to cha

Re: RFR: 8260555: Change the default TIMEOUT_FACTOR from 4 to 1 [v3]

On Tue, 19 Aug 2025 03:31:55 GMT, SendaoYan wrote: >> It is also something that can be changed later, in a follow up fix. > > Take test > test/hotspot/jtreg/compiler/arraycopy/stress/TestStressArrayCopy.java as > example. > If there is a bug in jvm with -Xcomp option which will cause this test

Re: RFR: 8365053: Refresh hotspot precompiled.hpp with headers based on current frequency [v10]

On Mon, 11 Aug 2025 01:46:43 GMT, Kim Barrett wrote: > Other optional features include cds, c1, jfr, and jvmci, so files from those > directories also ought to be excluded. Can't these just be conditionalized with an INCLUDE_xxx check instead of being excluded? - PR Comment: http

Re: RFR: 8365053: Refresh hotspot precompiled.hpp with headers based on current frequency

On Thu, 7 Aug 2025 19:55:35 GMT, Francesco Andreuzzi wrote: > For example, when the threshold is set to 50 I get this compilation error: How can we possibly get a compilation error when everything should build with PCH disabled? - PR Comment: https://git.openjdk.org/jdk/pull/26681

Re: malloc/calloc return value NULL check

On 11/07/2025 10:57 pm, Baesken, Matthias wrote: Hi, when playing around with the  GCC static analyzer  ( https:// developers.redhat.com/articles/2022/04/12/state-static-analysis-gcc-12- compiler )   I no

Re: RFR: 8320353: Reenable stringop-overflow warnings

On Tue, 1 Jul 2025 12:25:04 GMT, Anton Artemov wrote: > Hi, please consider the following changes: > > this PR addresses the issue of stringop-overflow warnings produced by GCC. > The compiler does think that the thread pointer returned by > `JavaThread::current()` can be null, though it cant.

Re: RFR: 8360478: libjsig related tier3 jtreg tests fail when asan is configured [v2]

On Thu, 26 Jun 2025 06:33:11 GMT, Matthias Baesken wrote: >> There are a number of :tier3 HS jtreg tests using libjsig. Unfortunately >> they clash with asan, so it should be avoided to run them if asan is >> configured. >> >> Examples : >> runtime/signal/TestSigalrm.java >> runtime/signal/Tes

Re: RFR: 8360478: libjsig related tier3 jtreg tests fail when asan is configured

On Wed, 25 Jun 2025 12:49:54 GMT, Matthias Baesken wrote: > There are a number of :tier3 HS jtreg tests using libjsig. Unfortunately they > clash with asan, so it should be avoided to run them if asan is configured. > > Examples : > runtime/signal/TestSigalrm.java > runtime/signal/TestSigbus.ja

Re: Questions about the Hermetic Java project

On 6/06/2025 1:23 am, Jiangli Zhou wrote: On Thu, Jun 5, 2025 at 1:33 AM David Holmes <mailto:david.hol...@oracle.com>> wrote: > > On 5/06/2025 1:33 am, Jiangli Zhou wrote: > > Ok, still thanks for the thoughts, David. > > > > To summarize, here is wh

Re: Questions about the Hermetic Java project

for the library, JNI_OnLoad_L can be called. That is an existing behavior since JDK 8. Need to document (in spec or release notes?). Best, Jiangli On Tue, Jun 3, 2025 at 9:31 PM David Holmes wrote: On 4/06/2025 5:00 am, Jiangli Zhou wrote: On Mon, Jun 2, 2025 at 6:22 PM David Holmes wrote: On

Re: Questions about the Hermetic Java project

On 4/06/2025 5:00 am, Jiangli Zhou wrote: On Mon, Jun 2, 2025 at 6:22 PM David Holmes wrote: On 3/06/2025 9:29 am, Jiangli Zhou wrote: On Sun, Jun 1, 2025 at 7:55 PM David Holmes wrote: On 31/05/2025 7:20 am, Jiangli Zhou wrote: On Thu, May 29, 2025 at 11:54 PM David Holmes wrote: On

Re: Questions about the Hermetic Java project

On 3/06/2025 9:29 am, Jiangli Zhou wrote: On Sun, Jun 1, 2025 at 7:55 PM David Holmes wrote: On 31/05/2025 7:20 am, Jiangli Zhou wrote: On Thu, May 29, 2025 at 11:54 PM David Holmes wrote: On 30/05/2025 9:26 am, Jiangli Zhou wrote: I just thought of one more thing related to the

Re: RFR: 8358284: doc/testing.html is not up to date after JDK-8355003

On Mon, 2 Jun 2025 03:43:06 GMT, Kim Barrett wrote: > Please review this trivial change to doc/testing.html, to bring it up to date > with the associated source file doc/testing.md. The change was produced by > running `make update-build-docs` in an up-to-date local repository. Seems okay. Than

Re: Questions about the Hermetic Java project

On 31/05/2025 7:20 am, Jiangli Zhou wrote: On Thu, May 29, 2025 at 11:54 PM David Holmes wrote: On 30/05/2025 9:26 am, Jiangli Zhou wrote: I just thought of one more thing related to the discussion now. Any concern if the implementation does not ignore JNI_OnLoad_L and etc if they are

Re: Questions about the Hermetic Java project

On 30/05/2025 9:26 am, Jiangli Zhou wrote: On Thu, May 29, 2025 at 3:17 PM David Holmes wrote: On 30/05/2025 2:57 am, Jiangli Zhou wrote: On Wed, May 28, 2025 at 10:36 PM David Holmes wrote: Hi Jiangli, On 29/05/2025 3:27 am, Jiangli Zhou wrote: This is unfortunately quite complex

Re: Questions about the Hermetic Java project

On 30/05/2025 2:57 am, Jiangli Zhou wrote: On Wed, May 28, 2025 at 10:36 PM David Holmes wrote: Hi Jiangli, On 29/05/2025 3:27 am, Jiangli Zhou wrote: This is unfortunately quite complex, and I have started a discussion with Alan if it is possible to update the JNI spec so that both

Re: Questions about the Hermetic Java project

Hi Jiangli, On 29/05/2025 3:27 am, Jiangli Zhou wrote: This is unfortunately quite complex, and I have started a discussion with Alan if it is possible to update the JNI spec so that both static and dynamic entry points can have the form "JNI_OnLoad_". Ideally, I'd like to see us push for th

Re: RFR: 8357511: [BACKOUT] 8357048: RunTest variables should always be assigned

On Wed, 21 May 2025 23:17:26 GMT, Mikael Vidstedt wrote: > Backing out JDK-8357048 which broke testing. > > Testing: tier5 (in progress) LGTM. Thanks for doing the backout. - Marked as reviewed by dholmes (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/25374#pullrequestre

Re: RFR: 8357000: Write overview documentation for start of release changes [v2]

On Tue, 20 May 2025 17:14:38 GMT, Joe Darcy wrote: >> First attempt to populate "supplementary docs" with a discussion of the >> start of release changes. For reference on the idea of supplementary docs, >> see the thread >> >> "Where to put supplementary docs?" >> https://mail.openjdk.org/pip

Re: RFR: 8357000: Write overview documentation for start of release changes

On Tue, 20 May 2025 04:30:57 GMT, Joe Darcy wrote: > First attempt to populate "supplementary docs" with a discussion of the start > of release changes. For reference on the idea of supplementary docs, see the > thread > > "Where to put supplementary docs?" > https://mail.openjdk.org/pipermail

Re: RFR: 8357000: Write overview documentation for start of release changes

On Tue, 20 May 2025 10:25:11 GMT, David Holmes wrote: > Do you want to include manpage updates here? To answer myself "no". To clarify for others there are quite a lot of things that have to happen at the "start" of a release, but the ones documented here are the ones

Re: RFR: 8356171: Increase timeout for testcases as preparation for change of default timeout factor

On Thu, 8 May 2025 14:51:24 GMT, Leo Korinth wrote: > This change tries to add timeout to individual testcases so that I am able to > run them with a timeout factor of 1 in the future (JDK-8260555). > > The first commit changes the timeout factor to 0.7, so that I can run tests > and test the

Re: RFR: 8356171: Increase timeout for testcases as preparation for change of default timeout factor

On Thu, 8 May 2025 14:51:24 GMT, Leo Korinth wrote: > This change tries to add timeout to individual testcases so that I am able to > run them with a timeout factor of 1 in the future (JDK-8260555). > > The first commit changes the timeout factor to 0.7, so that I can run tests > and test the

Re: RFR: 8355746: Start of release updates for JDK 26 [v2]

On Thu, 8 May 2025 13:18:07 GMT, Nizar Benalla wrote: >> Get JDK 26 underway. > > Nizar Benalla has updated the pull request with a new target base due to a > merge or a rebase. The pull request now contains seven commits: > > - Update release date > - Update --release 25 symbol information f

Re: RFR: 8354088: [BACKOUT] Run jtreg in the work dir

On Wed, 9 Apr 2025 01:27:01 GMT, Joe Darcy wrote: >> https://github.com/dholmes-ora/jdk/pull/new/8354088-backout >> >> This reverts commit bd73a0641615d743663ef652bc1f27305af1517b. >> >> It causes problems with paths to ProblemList files no longer being correct. >> >> Re-tested tier3 > > Marke

Integrated: 8354088: [BACKOUT] Run jtreg in the work dir

On Wed, 9 Apr 2025 00:54:25 GMT, David Holmes wrote: > https://github.com/dholmes-ora/jdk/pull/new/8354088-backout > > This reverts commit bd73a0641615d743663ef652bc1f27305af1517b. > > It causes problems with paths to ProblemList files no longer being correct. > > Re-te

RFR: 8354088: [BACKOUT] Run jtreg in the work dir

https://github.com/dholmes-ora/jdk/pull/new/8354088-backout This reverts commit bd73a0641615d743663ef652bc1f27305af1517b. It causes problems with paths to ProblemList files no longer being correct. Re-tested tier3 - Commit messages: - Revert "8300339: Run jtreg in the work dir" C

Re: RFR: 8301197: Make sure use of printf is correct and actually needed [v3]

On Fri, 4 Apr 2025 13:35:22 GMT, Magnus Ihse Bursie wrote: >> make/common/modules/GensrcCommon.gmk line 45: >> >>> 43: $$(call MakeTargetDir) >>> 44: $(PRINTF) "jdk=%s\nfull=%s\nrelease=%s\n" \ >>> 45: $(VERSION_NUMBER) $(VERSION_STRING) $(VERSION_SHORT) > $$@ >> >>

Re: RFR: 8300339: Run jtreg in the work dir

On Fri, 4 Apr 2025 14:59:35 GMT, Magnus Ihse Bursie wrote: > We had a test setup failure in our distributed test system where the process > running jtreg crashed. This caused the hs_err file to end up in the root of > the source tree. Dropping crash files in the source tree is bad practice and

Re: RFR: 8353449: [BACKOUT] One instance of STATIC_LIB_CFLAGS was missed in JDK-8345683

On Tue, 1 Apr 2025 12:41:48 GMT, David Holmes wrote: > Revert "8353272: One instance of STATIC_LIB_CFLAGS was missed in JDK-8345683" > > This reverts commit cef5610b5d4f7c5c2ceda46995ef3a0d961294e5. > > This causes failures building the static libs on Windows and macOS

Re: RFR: 8352935: Launcher should not add $JDK/../lib to LD_LIBRARY_PATH

On Tue, 1 Apr 2025 09:13:45 GMT, Joachim Kern wrote: > In the JDK launcher, there is a codepath which would set/modify the > LD_LIBRARY_PATH. This happens unconditionally on AIX and Linux/musl and can > also happen on other Linux platforms if an LD_LIBRARY_PATH is pre-set which > contains a li

Re: RFR: 8301197: Make sure use of printf is correct and actually needed

On Thu, 3 Apr 2025 13:36:16 GMT, Magnus Ihse Bursie wrote: > We have been sloppy in our use of `printf` in make code. Most of the time, we > should really use `echo` instead. If we do need to use `printf`, we should > never inline make or shell variables into the formatting string, since they

Re: RFR: 8301197: Make sure use of printf is correct and actually needed

On Thu, 3 Apr 2025 21:08:40 GMT, Magnus Ihse Bursie wrote: >> make/autoconf/help.m4 line 295: >> >>> 293: $ECHO "* HS debug level: $HOTSPOT_DEBUG_LEVEL" >>> 294: $ECHO "* JVM variants: $JVM_VARIANTS" >>> 295: $ECHO "* JVM features: " >> >> I believe this will now add a newline where t

Re: RFR: 8301197: Make sure use of printf is correct and actually needed

On Thu, 3 Apr 2025 21:07:50 GMT, Magnus Ihse Bursie wrote: >> make/Docs.gmk line 267: >> >>> 265:$$(call LogInfo, Creating overview.html for $1) >>> 266:$$(call MakeDir, $$(@D)) >>> 267:$$(PRINTF) "%s" '$$($1_OVERVIEW_TEXT)' > $$@ >> >> For my education, why isn't this j

Re: RFR: 8353458: Don't pass -Wno-format-nonliteral to CFLAGS

On Tue, 1 Apr 2025 13:22:47 GMT, Magnus Ihse Bursie wrote: > there was already a pragma but due to incorrect restrictions it did not apply > to clang. How does the `__GNUC__` check affect clang?? Isn't that just for gcc? - PR Comment: https://git.openjdk.org/jdk/pull/24357#issueco

Integrated: 8353449: [BACKOUT] One instance of STATIC_LIB_CFLAGS was missed in JDK-8345683

On Tue, 1 Apr 2025 12:41:48 GMT, David Holmes wrote: > Revert "8353272: One instance of STATIC_LIB_CFLAGS was missed in JDK-8345683" > > This reverts commit cef5610b5d4f7c5c2ceda46995ef3a0d961294e5. > > This causes failures building the static libs on Windows and macO

RFR: 8353449: [BACKOUT] One instance of STATIC_LIB_CFLAGS was missed in JDK-8345683

Revert "8353272: One instance of STATIC_LIB_CFLAGS was missed in JDK-8345683" This reverts commit cef5610b5d4f7c5c2ceda46995ef3a0d961294e5. This causes failures building the static libs on Windows and macOS. Thanks - Commit messages: - Revert "8353272: One instance of STATIC_LIB_C

Re: RFR: 8352506: Simplify make/test/JtregNativeHotspot.gmk

On Thu, 20 Mar 2025 22:40:51 GMT, Magnus Ihse Bursie wrote: >> make/test/JtregNativeHotspot.gmk line 121: >> >>> 119: -I$(VM_TESTBASE_DIR)/nsk/stress/jni \ >>> 120: -I$(VM_TESTBASE_DIR)/vm/mlvm/share \ >>> 121: -I$(VM_TESTBASE_DIR)/vm/share \ >> >> Including these directories for ev

Re: RFR: 8351322: Parameterize link option for pthreads [v2]

On Thu, 20 Mar 2025 12:38:37 GMT, Magnus Ihse Bursie wrote: > Is there any gain then in changing away from -lpthread? That is clearly > defined, link with libpthread, with no side effects. "If it ain't broke..." True - what we have works and using `-pthread` might subtly change things. ---

Re: RFR: 8352506: Simplify make/test/JtregNativeHotspot.gmk

On Thu, 20 Mar 2025 12:32:53 GMT, Magnus Ihse Bursie wrote: > The file to setup special arguments to native JTReg Hotspot tests is > needlessly complicated. With some generalisation, we can make it much simpler. make/test/JtregNativeHotspot.gmk line 121: > 119: -I$(VM_TESTBASE_DIR)/nsk/str

Re: RFR: 8351322: Parameterize link option for pthreads [v2]

On Fri, 7 Mar 2025 00:18:14 GMT, David Holmes wrote: >>> What is the intended way of using this? Do you run make with >>> LIBPTHREAD=-pthread or do you apply a patch on libraries.m4 for the >>> specific way of linking to pthread? >> >> This is in prep

Re: RFR: 8345169: Implement JEP 503: Remove the 32-bit x86 Port [v2]

On Mon, 10 Mar 2025 09:49:44 GMT, Aleksey Shipilev wrote: >> This PR implements JEP 503: Remove the 32-bit x86 Port. >> >> The JEP is proposed to target 25, we would not integrate until JEP is ready. >> Reviews are appreciated meanwhile. >> >> This is only the removal of obvious 32-bit x86 par

Re: RFR: 8352044: Add --with-import-jvms to configure

On Fri, 14 Mar 2025 17:58:50 GMT, Magnus Ihse Bursie wrote: >> This change copies `libjvm.so` _and_ sibling `.jsa` files, right? >> >> If so, then one thing is missing: regenerating CDS archives that have >> opinions on `modules` filesizes/dates for fingerprinting their CDS archives. >> My fra

Re: RFR: 8351309: test/hotspot/jtreg/runtime/posixSig/TestPosixSig.java fails on static-jdk

On Thu, 6 Mar 2025 19:22:23 GMT, Jiangli Zhou wrote: > How useful is signal chaining even these days? @magicus as useful as it has ever been if your application uses signals that overlap with JVM usage. - PR Comment: https://git.openjdk.org/jdk/pull/23924#issuecomment-2705751155

Re: RFR: 8351309: test/hotspot/jtreg/runtime/posixSig/TestPosixSig.java fails on static-jdk

On Thu, 6 Mar 2025 17:42:04 GMT, Jiangli Zhou wrote: > libjsig is provided by JDK. Yes for an application to chose to use so that its own signal usage can be better integrated with that of the JDK. Statically linking libjsig with a JDK makes no sense to me at all. > TestPosixSig.java failure

Re: RFR: 8345169: Implement JEP 503: Remove the 32-bit x86 Port

On Thu, 6 Mar 2025 18:23:24 GMT, Magnus Ihse Bursie wrote: >> I don't mind removing it, my concern would be to _remember_ this option was >> there! I guess it is okay to re-re-invent it later, possibly under a >> different name, when the next port gets deprecated. > > It's no that important, no

Re: RFR: 8345169: Implement JEP 503: Remove the 32-bit x86 Port

On Thu, 6 Mar 2025 09:48:47 GMT, Aleksey Shipilev wrote: > After this PR integrates, it is not possible to build x86_32 You could add a couple of lines to the build code and it would not be possible to build 32-bit, so that is a necessary but not sufficient condition to claim to implement the

Re: RFR: 8351322: Parameterize link option for pthreads

On Thu, 6 Mar 2025 15:47:58 GMT, Magnus Ihse Bursie wrote: >> What is the intended way of using this? Do you run make with >> `LIBPTHREAD=-pthread` or do you apply a patch on `libraries.m4` for the >> specific way of linking to pthread? > >> What is the intended way of using this? Do you run ma

Re: RFR: 8351322: Parameterize link option for pthreads

On Thu, 6 Mar 2025 10:39:27 GMT, snake66 wrote: > Replace hardcoded instances of `-lpthread` with `$(LIBPTHREAD)`, so that it's > possible to parameterize this for platforms that use different flags for > enabling posix threads. > > This work is a continuation of the work done by Greg Lewis in

Re: RFR: 8351309: test/hotspot/jtreg/runtime/posixSig/TestPosixSig.java fails on static-jdk

On Wed, 5 Mar 2025 22:59:06 GMT, Jiangli Zhou wrote: > Please review this PR that excludes `libjsig` from being statically linked > with `static-jdk` `java` launcher by default. Please see details in > https://bugs.openjdk.org/browse/JDK-8351309 description and comments. Thanks I am a bit conf

Re: RFR: 8350952: Remove some non present files from OPT_SPEED_SRC list

On Wed, 5 Mar 2025 08:41:06 GMT, Matthias Baesken wrote: > I wonder how useful this OPT_SPEED_SRC list is these days I suspect not useful at all. Too much has changed. This kind of list should be examined each time we update a toolchain. And in principle any new file should be evaluated to se

Re: RFR: 8345169: Implement JEP 503: Remove the 32-bit x86 Port

On Tue, 4 Mar 2025 16:52:16 GMT, Aleksey Shipilev wrote: > This PR implements JEP 503: Remove the 32-bit x86 Port. > > The JEP is proposed to target 25, we would not integrate until JEP is ready. > Reviews are appreciated meanwhile. > > This is only the removal of obvious 32-bit x86 parts, mos

Re: RFR: 8350952: Remove some non present files from OPT_SPEED_SRC list

On Tue, 4 Mar 2025 16:11:22 GMT, Matthias Baesken wrote: > JvmFeatures.gmk contains a file list OPT_SPEED_SRC , the list contains files > that have to be optimized for speed when the other files are optimized for > binary size. > However some non present files are mentioned and should be remove

Re: RFR: 8351241: Require minimum gcc version 12

On Wed, 5 Mar 2025 07:21:17 GMT, SendaoYan wrote: > After [JDK-8345627](https://bugs.openjdk.org/browse/JDK-8345627), the minumum > gcc version should be 12 Or JDK-8345627 change should only be enabled when gcc version is >= 12. - PR Comment: https://git.openjdk.org/jdk/pull/23913

Re: RFR: 8350903: Remove explicit libjvm.so dependency for libVThreadEventTest

On Fri, 28 Feb 2025 01:40:34 GMT, Jiangli Zhou wrote: > Please review the test fix that removes `libVThreadEventTest` explicit > dependency to `libjvm`, by removing the call to `JNI_GetCreatedJavaVMs` in > `Agent_OnAttach`. There is a `vm` argument passed via `Agent_OnAttach`. With > the chang

Re: RFR: 8348028: Unable to run gtests with CDS enabled [v4]

On Fri, 28 Feb 2025 00:37:24 GMT, Calvin Cheung wrote: >> A simple fix in `os::jvm_path()` so that gtest can be run with CDS >> (`-Xshare:on`). The fix is just to change the directory name from `hotspot` >> to `server`. >> Note that the bug doesn't exist on macOS and thus no change is required

Re: RFR: 8350819: Ignore core files

On Wed, 26 Feb 2025 22:26:58 GMT, Mikael Vidstedt wrote: > Core files may from time to time end up in the source tree of the JDK, adding > noise in git etc. Because we have valid files and directories called "core*" > in the tree it's non-trivial to exclude any and all core files, but as a > s

Re: RFR: 8350280: The JDK-8346050 testlibrary changes break the build

On Tue, 18 Feb 2025 20:49:27 GMT, Leonid Mesnik wrote: > Please review following trivial PR that fix library build by adding > --add-exports. > Testing: tier1 Seems reasonable - and trivial Thanks - Marked as reviewed by dholmes (Reviewer). PR Review: https://git.openjdk.org/jd

Re: RFR: 8349752: Tier1 build failure caused by JDK-8349178

On Mon, 10 Feb 2025 20:13:17 GMT, Jiangli Zhou wrote: > Add `BUILD_HOTSPOT_JTREG_LIBRARIES_LIBS_libatExit += -ldl` for linux target. I am at a loss to understand how the initial change built and tested with no problem even though `-ldl` was missing. Maybe there is some way to set a default set

Re: RFR: 8349752: Tier1 build failure caused by JDK-8349178

On Mon, 10 Feb 2025 20:13:17 GMT, Jiangli Zhou wrote: > Add `BUILD_HOTSPOT_JTREG_LIBRARIES_LIBS_libatExit += -ldl` for linux target. This matches other tests that use dlsym. I don't understand why this wasn't caught in pre-integration testing. Please integrate ASAP. Thanks. - Mark

Re: RFR: 8349284: Make libExplicitAttach work on static JDK [v4]

On Mon, 10 Feb 2025 04:00:44 GMT, Jiangli Zhou wrote: >> This is similar to https://github.com/openjdk/jdk/pull/23431 change. It >> removes libjvm.so as a recorded dependency for libExplicitAttach.so by not >> explicitly link libExplicitAttach.so with libjvm.so at build time. To do >> that, it

Re: RFR: 8349178: runtime/jni/atExit/TestAtExit.java should be supported on static JDK

On Tue, 4 Feb 2025 01:10:34 GMT, Jiangli Zhou wrote: > Please review runtime/jni/atExit/TestAtExit.java test change: > > - Remove `BUILD_HOTSPOT_JTREG_LIBRARIES_JDK_LIBS_libatExit := > java.base:libjvm`. Don't explicitly link with libjvm, because it adds > libjvm.so as a recorded dependency to

Re: RFR: 8349513: Remove unused BUILD_JDK_JTREG_LIBRARIES_JDK_LIBS_libTracePinnedThreads

On Thu, 6 Feb 2025 01:42:41 GMT, Jiangli Zhou wrote: > Please review this minor cleanup. The related jtreg test, > TracePinnedThreads.java/libTracePinnedThreads.c has already been removed by > https://github.com/openjdk/jdk/pull/21565 work (for > [JDK-8338383](https://bugs.openjdk.org/browse/J

Re: RFR: 8349140: Size optimization (opt-size) build fails after recent PCH changes

On Wed, 5 Feb 2025 06:35:43 GMT, Julian Waters wrote: >> There was no indication as to why `bytecodeInterpreter.cpp` was made no-PCH >> back in [JDK-6571248](https://bugs.openjdk.org/browse/JDK-6571248), and it >> appears to only have been for Windows. So removing it now seems reasonable, >> t

Integrated: 8349511: [BACKOUT] Framework for tracing makefile inclusion and parsing

On Thu, 6 Feb 2025 01:32:51 GMT, David Holmes wrote: > This reverts commit 61465883b465a184e31e7a03e2603d29ab4815a4. > > JDK-8348190: Framework for tracing makefile inclusion and parsing > > The above issue caused problems in the Oracle closed builds and so needs to > be bac

Re: RFR: 8349511: [BACKOUT] Framework for tracing makefile inclusion and parsing

On Thu, 6 Feb 2025 02:48:21 GMT, Mikael Vidstedt wrote: >> This reverts commit 61465883b465a184e31e7a03e2603d29ab4815a4. >> >> JDK-8348190: Framework for tracing makefile inclusion and parsing >> >> The above issue caused problems in the Oracle closed builds and so needs to >> be backed out un

Re: RFR: 8349511: [BACKOUT] Framework for tracing makefile inclusion and parsing

On Thu, 6 Feb 2025 02:01:47 GMT, Joe Darcy wrote: >> This reverts commit 61465883b465a184e31e7a03e2603d29ab4815a4. >> >> JDK-8348190: Framework for tracing makefile inclusion and parsing >> >> The above issue caused problems in the Oracle closed builds and so needs to >> be backed out until th

RFR: 8349511: [BACKOUT] Framework for tracing makefile inclusion and parsing

This reverts commit 61465883b465a184e31e7a03e2603d29ab4815a4. JDK-8348190: Framework for tracing makefile inclusion and parsing The above issue caused problems in the Oracle closed builds and so needs to be backed out until that is addressed. Thanks. - Commit messages: - Revert "

Re: RFR: 8349140: Size optimization (opt-size) build fails after recent PCH changes

On Wed, 5 Feb 2025 03:35:51 GMT, David Holmes wrote: >> I think bytecodeInterpreterWithChecks was removed a long time ago. It is >> still referenced in 8u-dev: >> https://github.com/openjdk/jdk8u-dev/blob/master/hotspot/src/share/vm/interpreter/bytecodeInterpreterWithChecks.x

Re: RFR: 8349140: Size optimization (opt-size) build fails after recent PCH changes

On Tue, 4 Feb 2025 15:35:03 GMT, Matthias Baesken wrote: > When using the configure flag --enable-jvm-feature-opt-size (linux x86_64 opt > build, gcc 11 devkit) we run into this error after the recent PCH related > changes : > > > cc1plus: error: > /build_optsize/hotspot/variant-server/libjv

Re: RFR: 8349140: Size optimization (opt-size) build fails after recent PCH changes

On Tue, 4 Feb 2025 16:29:46 GMT, Martin Doerr wrote: >> On closer inspection bytecodeInterpreterWithChecks.cpp might be a remnant of >> the old Interpreter that no longer exists. Alright, this should be ok then > > I think bytecodeInterpreterWithChecks was removed a long time ago. It is > still

Re: RFR: 8323158: HotSpot Style Guide should specify more include ordering [v2]

On Mon, 3 Feb 2025 12:14:35 GMT, Stefan Karlsson wrote: >> The HotSpot Style Guide has a section about source files and includes. The >> style used for includes have mostly been introduced by scripts when >> includeDB was replaced, but also when various other enhancements to our >> includes we

Re: RFR: 8349178: runtime/jni/atExit/TestAtExit.java should be supported on static JDK

On Tue, 4 Feb 2025 17:17:17 GMT, Jiangli Zhou wrote: > Also to point it out if it's not clear already, libjvm.so is implementation > detail. One cannot safely that exists at runtime. The static JDK case is a > good example. Is there any other example? Presuming the existence of dynamic linked

Re: RFR: 8349178: runtime/jni/atExit/TestAtExit.java should be supported on static JDK

On Tue, 4 Feb 2025 19:42:42 GMT, Jiangli Zhou wrote: >>> @jianglizhou I will be brutally honest and say that I do not like this at >>> all. Does this mean all JNI using tests/applications have to becoded >>> differently to be used with a static JDK? I find it somewhat ironic that to >>> work w

Re: RFR: 8349178: runtime/jni/atExit/TestAtExit.java should be supported on static JDK

On Tue, 4 Feb 2025 01:10:34 GMT, Jiangli Zhou wrote: > Please review runtime/jni/atExit/TestAtExit.java test change: > > - Remove `BUILD_HOTSPOT_JTREG_LIBRARIES_JDK_LIBS_libatExit := > java.base:libjvm`. Don't explicitly link with libjvm, because it adds > libjvm.so as a recorded dependency to

Re: RFR: 8348207: Linux PPC64 PCH build broken after JDK-8347909

On Thu, 23 Jan 2025 23:53:01 GMT, Magnus Ihse Bursie wrote: >> The Linux PPC64 PCH build was broken after JDK-8347909. >> Build error >> >> * For target hotspot_variant-server_libjvm_objs_sharedRuntimeTrans.o: >> cc1plus: error: >> /jdk25_opt/hotspot/variant-server/libjvm/objs/precompiled/preco

Re: RFR: 8348286: [AIX] clang 17 introduces new warning Wtentative-Definitions which produces Build errors

On Wed, 22 Jan 2025 15:34:36 GMT, Joachim Kern wrote: > We (SAP) try to introduce the ‘IBM Open XL C/C++ for AIX 17.1.2’ (based on > clang 17) as a feasible compiler for jdk25, because in combination with the > 17.1.3 runtime this would enable the support for ubsan. > Unfortunately, the new com

Re: RFR: 8348180: Remove mention of include of precompiled.hpp from the HotSpot Style Guide [v2]

On Wed, 22 Jan 2025 09:34:18 GMT, Stefan Karlsson wrote: >> [JDK-8347909](https://bugs.openjdk.org/browse/JDK-8347909) removed the need >> for HotSpot devs to include the precompiled.hpp. This is the PR to reflect >> that. >> >> I know that there is some process around updating the style guide

Re: RFR: 8348182: Remove DONT_USE_PRECOMPILED_HEADER

On Tue, 21 Jan 2025 12:41:13 GMT, Stefan Karlsson wrote: > Before [JDK-8347909](https://bugs.openjdk.org/browse/JDK-8347909) we had to > remove the include lines in precompiled.hpp when precompiled headers were > turned off. This was done by defining DONT_USE_PRECOMPILED_HEADER. > > After [JDK

Re: RFR: 8347909: Automatic precompiled.hpp inclusion [v3]

On Thu, 16 Jan 2025 18:49:51 GMT, Stefan Karlsson wrote: >> HotSpot uses precompiled headers to speed up non-incremental builds. The >> current mechanism requires all .cpp files to include precompiled.hpp as the >> first non-comment line. This requires HotSpot devs to think about >> precompile

  1   2   3   4   5   6   >