On Mon, 22 Sep 2025 15:32:27 GMT, Matthias Baesken wrote:
>> A couple of JDK native libs link to $(LIBDL) , but some do not use symbols
>> from it.
>
> Matthias Baesken has updated the pull request incrementally with one
> additional commit since the last revision:
>
> libsyslookup - bring b
On Thu, 18 Sep 2025 07:20:55 GMT, Matthias Baesken wrote:
> A couple of JDK native libs link to $(LIBDL) , but some do not use symbols
> from it.
+1
-
Marked as reviewed by mdoerr (Reviewer).
PR Review: https://git.openjdk.org/jdk/pull/27358#pullrequestreview-3239571890
On Tue, 6 May 2025 15:39:04 GMT, Magnus Ihse Bursie wrote:
>> Most of the JDK code base has been transitioned to UTF-8, but not all. This
>> has recently become an acute problem, since our mixing of iso-8859-1 and
>> utf-8 in properties files confused the version of `sed` that is shipped with
On Wed, 16 Apr 2025 09:51:49 GMT, Magnus Ihse Bursie wrote:
> `locale -a`
C
POSIX
en_US.8859-15
en_US.IBM-858
en_US.ISO8859-1
en_US
I don't know if UTF-8 can be installed. If so, we should also document that as
requirement for AIX build machines.
-
PR Comment: https://git.openj
On Mon, 14 Apr 2025 12:53:35 GMT, Magnus Ihse Bursie wrote:
>> Most of the JDK code base has been transitioned to UTF-8, but not all. This
>> has recently become an acute problem, since our mixing of iso-8859-1 and
>> utf-8 in properties files confused the version of `sed` that is shipped with
On Thu, 10 Apr 2025 08:19:19 GMT, Matthias Baesken wrote:
> On linux ppc64 / gcc , we build with the compile flag
> -minsert-sched-nops=regroup_exact ; this is most likely outdated, maybe it
> was still useful for old Power6 machines.
>
> See
> https://gcc.gnu.org/onlinedocs/gcc-11.1.0/gcc/RS
On Thu, 27 Mar 2025 02:57:23 GMT, SendaoYan wrote:
> Hi all,
>
> Apologize for the inconvenience, fix of
> [JDK-8352481](https://bugs.openjdk.org/browse/JDK-8352481) make AIX build
> broekn.
>
> According to the implementation of makefile function
> `FLAGS_SETUP_LDFLAGS_HELPER` which locate
On Tue, 11 Mar 2025 09:12:45 GMT, David Linus Briemann wrote:
>> Add an .editorconfig to define indentation, trim trailing whitespace and
>> open curly brace position for C++ and Java.
>> This allows various editors to easily infer basics of the coding style.
>
> David Linus Briemann has updated
On Thu, 27 Mar 2025 02:57:23 GMT, SendaoYan wrote:
> Hi all,
>
> Apologize for the inconvenience, fix of
> [JDK-8352481](https://bugs.openjdk.org/browse/JDK-8352481) make AIX build
> broekn.
>
> According to the implementation of makefile function
> `FLAGS_SETUP_LDFLAGS_HELPER` which locate
On Tue, 25 Mar 2025 10:43:32 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
On Fri, 21 Mar 2025 11:44:49 GMT, Joachim Kern wrote:
>> After "JDK-8339480: Build static-jdk image with a statically linked
>> launcher" AIX was not able to build the new target. Therefore with
>> "JDK-8345590 AIX 'make all' fails after JDK-8339480" the new target was
>> disabled again.
>>
>
On Fri, 21 Mar 2025 16:19:38 GMT, Joachim Kern wrote:
>> After "JDK-8339480: Build static-jdk image with a statically linked
>> launcher" AIX was not able to build the new target. Therefore with
>> "JDK-8345590 AIX 'make all' fails after JDK-8339480" the new target was
>> disabled again.
>>
>
On Fri, 7 Mar 2025 09:28:15 GMT, Joachim Kern wrote:
> With
> [JDK-8348663](https://bugs.openjdk.org/browse/JDK-8348663) [AIX] clang
> pollutes the burned-in library search paths of the generated executables
> an ugly workaround was introduced to get rid of the unwanted list of search
> librari
On Wed, 19 Feb 2025 15:13:38 GMT, Matthias Baesken wrote:
> Currently we only set mcpu/mtune for hotspot; this might be a little
> problematic because other options might be used in the jdk native libs
> compilation .
> Those other (compared to hotspot) options are defined by the gcc - version
On Mon, 17 Feb 2025 14:00:01 GMT, Matthias Baesken wrote:
> Currently we tune for older Power8 CPUs in the libjvm build, this should be
> adjusted to current Power10.
>
> We do not set (yet) mcpu / mtune in the other native compilation units in the
> linux ppc64le build; this should we reconsi
On Fri, 14 Feb 2025 15:04:42 GMT, Matthias Baesken wrote:
> When using a gcc 13.2.0 devkit, the Linux builds (x86_64 and ppc64le) fail
> with warnings as errors in case that ubsan is enabled.
> The 2 warnings as errors are about memset usages ; we see those issues with
> gcc 13.2 but did not se
On Thu, 6 Feb 2025 08:58:17 GMT, Matthias Baesken wrote:
> The special optimization settings for jvmtiEnterTrace.cpp on AIX can be
> removed ; the file compiles now some seconds with or without this workaround.
> The special settings were needed for ancient versions of xlC.
LGTM.
On Tue, 4 Feb 2025 16:21:05 GMT, Julian Waters wrote:
>> I cannot find a bytecodeInterpreterWithChecks.cpp , where is this located ?
>> Regarding bytecodeInterpreter.cpp I see no differences in opt setting, so
>> far I don't know why this one should be excluded .
>
> On closer inspection byte
On Fri, 24 Jan 2025 09:09:15 GMT, Matthias Baesken wrote:
> When building on Linux ppc64le with the clang toolchain, the new JVM fails
> already in the build process with an error/crash :
>
>
> # SIGILL (0x4) at pc=0x79198fae03ac, pid=2922849, tid=2923410
> #
> # Problematic frame:
> # v ~
On Fri, 24 Jan 2025 14:58:24 GMT, Matthias Baesken 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/precomp
On Fri, 24 Jan 2025 09:09:15 GMT, Matthias Baesken wrote:
> When building on Linux ppc64le with the clang toolchain, the new JVM fails
> already in the build process with an error/crash :
>
>
> # SIGILL (0x4) at pc=0x79198fae03ac, pid=2922849, tid=2923410
> #
> # Problematic frame:
> # v ~
On Thu, 23 Jan 2025 12:59:19 GMT, Matthias Baesken 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/precompiled.h
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
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
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
On Thu, 12 Dec 2024 14:14:18 GMT, Matthias Baesken wrote:
> On AIX we after [JDK-8339480](https://bugs.openjdk.org/browse/JDK-8339480)
> into this error
>
>
> make all
> Building target 'all' in configuration '/open_jdk/jdk/build_aix'
> Creating 1 test executable file(s) for BUILD_LIBTEST_JTRE
On Thu, 24 Oct 2024 09:28:13 GMT, Amit Kumar wrote:
>>> But then, what exactly is the error? If it's just the test assuming that
>>> cache line size is log 6, then the test should be fixed for ppc, not
>>> hotspot.
>>
>> that is the problem, test assumes log2 of 6 for chacheline size
>
> PPC l
On Tue, 22 Oct 2024 13:53:03 GMT, Thomas Stuefe wrote:
>> I will do some benchmarks
>
> I did SpecJBB runs with shift of 6, 8 and 10, respectively, which amounts to
> Klass alignment of 64, 256 and 1K. Benchmark scores did not show a
> significant pattern. I did not measure CPU stats though.
>
On Tue, 8 Oct 2024 16:30:47 GMT, Roman Kennke wrote:
>> This is the main body of the JEP 450: Compact Object Headers (Experimental).
>>
>> It is also a follow-up to #20640, which now also includes (and supersedes)
>> #20603 and #20605, plus the Tiny Class-Pointers parts that have been
>> previ
On Tue, 1 Oct 2024 15:46:01 GMT, Roman Kennke wrote:
>>> Indeed, I could re-enable all tests in:
>>>
>>> ```
>>> test/hotspot/jtreg/compiler/c2/irTests/TestVectorizationMismatchedAccess.java
>>> test/hotspot/jtreg/compiler/c2/irTests/TestVectorizationNotRun.java
>>> test/hotspot/jtreg/compiler/l
On Mon, 14 Oct 2024 13:08:32 GMT, Aleksey Shipilev wrote:
> This implicitly fixes x86-32 builds that fail at runtime, because late
> barrier expansion is not implemented for them. I think about this check as
> something that we should have done as part of original JDK-8334060.
>
> The first ve
On Mon, 14 Oct 2024 13:08:32 GMT, Aleksey Shipilev wrote:
> This implicitly fixes x86-32 builds that fail at runtime, because late
> barrier expansion is not implemented for them. I think about this check as
> something that we should have done as part of original JDK-8334060.
>
> The first ve
On Tue, 3 Sep 2024 07:26:53 GMT, Matthias Baesken wrote:
>> We get a couple of warnings as errors on AIX because of unused variables or
>> functions , for example :
>> /priv/jenkins/client-home/workspace/openjdk-jdk-dev-aix_ppc64-opt/jdk/src/java.base/unix/native/libjava/ProcessHandleImpl_unix.c
On Mon, 2 Sep 2024 13:25:51 GMT, Matthias Baesken wrote:
>> We get a couple of warnings as errors on AIX because of unused variables or
>> functions , for example :
>> /priv/jenkins/client-home/workspace/openjdk-jdk-dev-aix_ppc64-opt/jdk/src/java.base/unix/native/libjava/ProcessHandleImpl_unix.c
On Tue, 30 Apr 2024 16:36:52 GMT, Kim Barrett wrote:
>> I will do after labor day and create a PR with this suggested solution in
>> your JDK-8330539.
>
> I think I still prefer just unconditionally including in
> globalDefinitions_gcc.hpp. For gcc/clang we are using `-std=c++14` +
> `-D_GNU
On Thu, 2 May 2024 09:54:14 GMT, Joachim Kern wrote:
> We need to find a better way to handle alloca on AIX.
>
> See the discussion in the PR for https://bugs.openjdk.org/browse/JDK-8329257,
> e.g. https://github.com/openjdk/jdk/pull/18536#discussion_r1568650313 in
> which three alternatives a
On Thu, 18 Apr 2024 04:26:21 GMT, Kim Barrett wrote:
>> I opened https://bugs.openjdk.org/browse/JDK-8330539 so we don't lose track
>> of this, but we can keep the discussion/voting here.
>
> For the impatient, I suggest adopting mechanism 2, i.e. unconditionally
> include in globalDefinitions_
On Mon, 29 Apr 2024 12:15:55 GMT, Matthias Baesken wrote:
> Currently we run into some alignment related issues when building with
> '--enable-ubsan' . Those errors already occur in the build. Fixing them might
> take some time and maybe also some discussion if it is worth the effort ,
> So for
On Wed, 17 Apr 2024 12:22:10 GMT, Magnus Ihse Bursie wrote:
>> I don't mind all 3, though I certainly prefer 1 and 3 over 2 (The way I see
>> it, the AIX macro check is more of a message to the programmer than it is
>> important to the compiler, so I prefer the options that have it. However, I
On Mon, 15 Apr 2024 11:46:25 GMT, Magnus Ihse Bursie wrote:
>> Should also remove the `#pragma alloca` in os_aix.cpp.
>
> It was too bad that I did not see and review this change in the makefiles. :-(
>
> While you guys could have gone either way, I strongly dislike the choice to
> include a re
On Fri, 12 Apr 2024 12:26:06 GMT, Magnus Ihse Bursie wrote:
> Unfortunately, after
> [JDK-8329704](https://bugs.openjdk.org/browse/JDK-8329704) AIX fails to
> build. The reason is that libjli is specially treated on AIX, and built like
> a static library. I tried to compensate for this (and ha
On Wed, 10 Apr 2024 12:15:34 GMT, Joachim Kern wrote:
>> As of [JDK-8325880](https://bugs.openjdk.org/browse/JDK-8325880), building
>> the JDK requires version 17 of IBM Open XL C/C++ (xlc). This is in effect
>> clang by another name, and it uses the clang toolchain in the JDK build.
>> Thus t
On Wed, 10 Apr 2024 13:35:39 GMT, Julian Waters wrote:
>> Yes I believe. I will remove the `#pragma alloca` everywhere, I will remove
>> the `#include ` everywhere and I will add
>> `-Dalloca=__builtin_alloca` to the compile commands. If it works I will
>> update the PR.
>
> In my humble opin
On Tue, 9 Apr 2024 17:25:04 GMT, Stewart X Addison wrote:
>> Pinging @sxa - what build environment does temurin use for AIX?
>
> Currently XLC16 but looking to upgrade to XLC17 on the minimum supported
> level for it (So it wouldn't be SP7 at present). Thanks for the ping - we
> have no current
On Wed, 10 Apr 2024 10:00:02 GMT, Martin Doerr wrote:
>> If I omit this #include
>> I get compiler errors of the following kind
>>
>> .../src/hotspot/share/runtime/javaThread.cpp::24: error: use of
>> undeclared identifier 'alloca&
On Wed, 10 Apr 2024 09:40:16 GMT, Joachim Kern wrote:
>> Do we even need to include ?
>>
>> From the Linux man page for alloca:
>>
>> By necessity, alloca() is a compiler built-in, also known as
>> __builtin_alloca(). By default, modern compilers automatically
>> translate all uses of alloca(
On Tue, 2 Apr 2024 11:22:54 GMT, Joachim Kern wrote:
>> I'd prefer having less AIX specific parts in this file. Can this be moved
>> somewhere else? Or maybe combine it with the AIX code above?
>
> My question is, do we need this block, because now already configure warns
> about an outdated co
On Thu, 28 Mar 2024 16:53:39 GMT, Joachim Kern wrote:
>> As of [JDK-8325880](https://bugs.openjdk.org/browse/JDK-8325880), building
>> the JDK requires version 17 of IBM Open XL C/C++ (xlc). This is in effect
>> clang by another name, and it uses the clang toolchain in the JDK build.
>> Thus t
On Wed, 14 Feb 2024 22:43:37 GMT, Kim Barrett wrote:
> Please review this change that updates the minimum supported version of IBM
> Open XL C/C++. SAP dropped support for older versions in JDK 22, only
> supporting the version specified in this change.
>
> I need someone from the aix-ppc porte
On Sat, 17 Feb 2024 08:28:56 GMT, Kim Barrett wrote:
> Please review this change that updates the minimum supported version of gcc
> to be used for building OpenJDK from 6.0 to 10.0.
>
> This permits enabling C++17 (JDK-8314488), though gcc 9.0 might suffice for
> that. A minimum of gcc 10 also
On Wed, 14 Feb 2024 22:43:37 GMT, Kim Barrett wrote:
> Please review this change that updates the minimum supported version of IBM
> Open XL C/C++. SAP dropped support for older versions in JDK 22, only
> supporting the version specified in this change.
>
> I need someone from the aix-ppc porte
On Mon, 5 Feb 2024 08:26:55 GMT, Martin Doerr wrote:
> A trivial ADLC build fix. The ADLC_LANGSTD_CXXFLAGS should get passed.
Thanks for the reviews!
-
PR Comment: https://git.openjdk.org/jdk/pull/17705#issuecomment-1928892061
On Mon, 5 Feb 2024 08:26:55 GMT, Martin Doerr wrote:
> A trivial ADLC build fix. The ADLC_LANGSTD_CXXFLAGS should get passed.
This pull request has now been integrated.
Changeset: 9ee9f288
Author: Martin Doerr
URL:
https://git.openjdk.org/jdk/com
A trivial ADLC build fix. The ADLC_LANGSTD_CXXFLAGS should get passed.
-
Commit messages:
- 8325213: Flags introduced by configure script are not passed to ADLC build
Changes: https://git.openjdk.org/jdk/pull/17705/files
Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=17705&range=
On Thu, 11 Jan 2024 13:04:35 GMT, Julian Waters wrote:
> There is a typo in adlc:
>
> ```
> diff --git a/make/hotspot/gensrc/GensrcAdlc.gmk
> b/make/hotspot/gensrc/GensrcAdlc.gmk
> index 0898d91e1c2..bb356476847 100644
> --- a/make/hotspot/gensrc/GensrcAdlc.gmk
> +++ b/make/hotspot/gensrc/Gensr
On Tue, 30 Jan 2024 14:02:41 GMT, Matthias Baesken wrote:
>>> Yes there is a nice define in the AIX header
>>
>> *sigh* On linux, they go to some lengths to avoid this, using a __REDEFINE
>> mechanism. Oh well.
>>
>> Anyway, I think this particular can be resolved by not including the
>> sta
On Sat, 13 Jan 2024 17:29:58 GMT, Christoph Langer wrote:
> Hi all,
>
> This pull request contains a backport of
> [JDK-8323008](https://bugs.openjdk.org/browse/JDK-8323008), commit
> [68c42860](https://github.com/openjdk/jdk/commit/68c4286026bc2c0ec0f594e0b96fe03fe5624d6d)
> from the [openjd
On Thu, 11 Jan 2024 13:23:45 GMT, Julian Waters wrote:
>> Compile the JDK as C++17, enabling the use of all C++17 language features
>
> Julian Waters has updated the pull request incrementally with one additional
> commit since the last revision:
>
> Require clang 13 in toolchain.m4
Thanks!
On Thu, 11 Jan 2024 12:36:31 GMT, Martin Doerr wrote:
>> Regarding
>> https://github.com/TheShermanTanker/jdk/actions/runs/7070564987/job/19247370401,
>> could it be that the adlc build didn't get the correct C++ version flags?
>> It doesn't loo
On Thu, 11 Jan 2024 11:33:07 GMT, Martin Doerr wrote:
>> Julian Waters has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Remove unnecessary -std=c++17 option in Lib.gmk
>
> Regarding
> https://github.com/
On Wed, 10 Jan 2024 13:11:38 GMT, Julian Waters wrote:
>> Compile the JDK as C++17, enabling the use of all C++17 language features
>
> Julian Waters has updated the pull request incrementally with one additional
> commit since the last revision:
>
> Remove unnecessary -std=c++17 option in Li
On Wed, 10 Jan 2024 13:11:38 GMT, Julian Waters wrote:
>> Compile the JDK as C++17, enabling the use of all C++17 language features
>
> Julian Waters has updated the pull request incrementally with one additional
> commit since the last revision:
>
> Remove unnecessary -std=c++17 option in Li
On Fri, 15 Dec 2023 08:08:10 GMT, Julian Waters wrote:
>> Implementation of [JEP draft: Compile the JDK as
>> C++17](https://bugs.openjdk.org/browse/JDK-8310260)
>
> Julian Waters has updated the pull request with a new target base due to a
> merge or a rebase. The incremental webrev excludes t
On Tue, 21 Nov 2023 19:30:30 GMT, suchismith1993 wrote:
>> The math library in AIX specifically, is a static archive. Doing a -lm wont
>> suffice, because when the symbols are looked up using dlsym or accessing
>> native code through Java, it will lead to failures.
>> Hence we had to come up wi
On Tue, 21 Nov 2023 17:49:43 GMT, suchismith1993 wrote:
>> The math library in AIX specifically, is a static archive. Doing a -lm wont
>> suffice, because when the symbols are looked up using dlsym or accessing
>> native code through Java, it will lead to failures.
>> Hence we had to come up wi
On Tue, 21 Nov 2023 17:54:08 GMT, suchismith1993 wrote:
>> src/java.base/aix/native/libsyslookup/syslookup.c line 30:
>>
>>> 28: #include
>>> 29: #include
>>> 30: #include
>>
>> Are string.h and stdlib.h needed? I can't see them in the comments below.
>
> string.h is needed for strlen. Let m
On Tue, 21 Nov 2023 13:01:50 GMT, suchismith1993 wrote:
>> The math library in AIX specifically, is a static archive. Doing a -lm wont
>> suffice, because when the symbols are looked up using dlsym or accessing
>> native code through Java, it will lead to failures.
>> Hence we had to come up wi
On Tue, 21 Nov 2023 13:01:50 GMT, suchismith1993 wrote:
>> The math library in AIX specifically, is a static archive. Doing a -lm wont
>> suffice, because when the symbols are looked up using dlsym or accessing
>> native code through Java, it will lead to failures.
>> Hence we had to come up wi
On Tue, 21 Nov 2023 11:52:23 GMT, suchismith1993 wrote:
>> The math library in AIX specifically, is a static archive. Doing a -lm wont
>> suffice, because when the symbols are looked up using dlsym or accessing
>> native code through Java, it will lead to failures.
>> Hence we had to come up wi
On Tue, 21 Nov 2023 11:21:40 GMT, suchismith1993 wrote:
>> The math library in AIX specifically, is a static archive. Doing a -lm wont
>> suffice, because when the symbols are looked up using dlsym or accessing
>> native code through Java, it will lead to failures.
>> Hence we had to come up wi
On Fri, 17 Nov 2023 12:45:32 GMT, suchismith1993 wrote:
> And I still don't understand if this is the list of symbols that are required
> by our tests, or the complete list of symbols that FFI `defaultLookup`
> returns to user applications. If it is the latter, then this is sort-of okay
> as a
On Mon, 13 Nov 2023 11:47:52 GMT, suchismith1993 wrote:
>>> There is not generic way of generating this. It needs a manual intervention
>>> and symbols are to be added on a need basis in future. Looks like a list to
>>> be maintained. I had tried adding comments to explain the list, but that
>
On Mon, 30 Oct 2023 10:54:48 GMT, suchismith1993 wrote:
> 1. Adding required compiler flags.
> 2. Adding required symbols.
>
> JBS-ISSUE : [JDK-8317799](https://bugs.openjdk.org/browse/JDK-8317799)
Changes requested by mdoerr (Reviewer).
LGTM. You may want to replace the Copyright header of th
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)
We're not changing it for existing releases. I don't think non-LTS releases
play a significant role regarding such compatibility. Next
On Wed, 6 Sep 2023 10:04:35 GMT, Jorn Vernee wrote:
>> This patch contains the implementation of the foreign linker & memory API
>> JEP for Java 22. The initial patch is composed of commits brought over
>> directly from the [panama-foreign
>> repo](https://github.com/openjdk/panama-foreign). T
On Mon, 14 Aug 2023 07:48:00 GMT, Matthias Baesken wrote:
> Currently there is a number of functionality that would be interesting to
> have for shared lib load operations in the JDK C code.
> Some examples :
> Events::log_dll_message for hs-err files reporting
> JFR event NativeLibraryLoad
> Th
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)
Successfully tested on AIX with xlc 17.1.1. Works for us (SAP). Please check
with others who might still use an older compiler (IBM).
On Wed, 14 Jun 2023 10:07:01 GMT, Christian Stein wrote:
> Hi all,
>
> This pull request contains a backport of commit
> [8aad881e](https://github.com/openjdk/jdk/commit/8aad881e803fddc26f45270f779ff0c0e5a095d8)
> from the [openjdk/jdk](https://git.openjdk.org/jdk) repository.
>
> The commit
On Wed, 14 Jun 2023 10:07:01 GMT, Christian Stein wrote:
> Hi all,
>
> This pull request contains a backport of commit
> [8aad881e](https://github.com/openjdk/jdk/commit/8aad881e803fddc26f45270f779ff0c0e5a095d8)
> from the [openjdk/jdk](https://git.openjdk.org/jdk) repository.
>
> The commit
On Wed, 7 Jun 2023 11:23:26 GMT, JoKern65 wrote:
>> This pr is a split off from JDK-8308288: Fix xlc17 clang warnings in shared
>> code https://github.com/openjdk/jdk/pull/14146
>> It handles the part in java.base.
>>
>> Compiling on AIX with xlc17 which contains the new clang 15 frontend
>> sh
On Wed, 7 Jun 2023 09:03:27 GMT, JoKern65 wrote:
>> This pr is a split off from JDK-8308288: Fix xlc17 clang warnings in shared
>> code https://github.com/openjdk/jdk/pull/14146
>> It handles the part in java.base.
>>
>> Compiling on AIX with xlc17 which contains the new clang 15 frontend
>> sh
On Fri, 2 Jun 2023 10:19:53 GMT, JoKern65 wrote:
> This pr is a split off from JDK-8308288: Fix xlc17 clang warnings in shared
> code https://github.com/openjdk/jdk/pull/14146
> It handles the part in security and servicability.
>
> Compiling on AIX with xlc17 which contains the new clang 15 fr
On Fri, 2 Jun 2023 18:24:16 GMT, Y. Srinivas Ramakrishna
wrote:
>> Kelvin Nilsen has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Force PLAB sizes to align on card-table size
>
> src/hotspot/cpu/riscv/gc/shenandoah/c1/shenandoahBarrierSe
On Fri, 2 Jun 2023 02:49:25 GMT, Kelvin Nilsen wrote:
>> OpenJDK Colleagues:
>>
>> Please review this proposed integration of Generational mode for Shenandoah
>> GC under https://bugs.openjdk.org/browse/JDK-8307314.
>>
>> Generational mode of Shenandoah is enabled by adding
>> `-XX:+UnlockExp
On Fri, 26 May 2023 20:46:29 GMT, Kelvin Nilsen wrote:
> OpenJDK Colleagues:
>
> Please review this proposed integration of Generational mode for Shenandoah
> GC under https://bugs.openjdk.org/browse/JDK-8307314.
>
> Generational mode of Shenandoah is enabled by adding
> `-XX:+UnlockExperimen
On Fri, 26 May 2023 16:58:41 GMT, Thomas Stuefe wrote:
>> The crazy thing is that `malloc` is defined! That means all places where we
>> use the term malloc are getting replaced without such a workaround. (E.g.
>> for log tags.)
>
> So, we do this only for malloc? Not for calloc, posix_memalign
On Fri, 26 May 2023 08:31:46 GMT, JoKern65 wrote:
>> When using the new xlc17 compiler (based on a recent clang) to build OpenJDk
>> on AIX , we run into various "warnings as errors".
>> Some of those are in shared codebase and could be addressed by small
>> adjustments.
>> A lot of those chang
On Thu, 25 May 2023 15:04:32 GMT, Kim Barrett wrote:
>> When using the new xlc17 compiler (based on a recent clang) to build OpenJDk
>> on AIX , we run into various "warnings as errors".
>> Some of those are in shared codebase and could be addressed by small
>> adjustments.
>> A lot of those ch
On Fri, 12 May 2023 21:51:59 GMT, Kim Barrett wrote:
>> src/hotspot/cpu/ppc/c1_LIRGenerator_ppc.cpp line 426:
>>
>>> 424: // Missing test if instr is commutative and if we should swap.
>>> 425: if (right.value()->type()->as_LongConstant() &&
>>> 426: (x->op() == Bytecodes::_lsub &&
>>
On Fri, 12 May 2023 16:16:01 GMT, JoKern65 wrote:
>> When using the new xlc17 compiler (based on a recent clang) to build OpenJDk
>> on AIX , we run into various "warnings as errors".
>> Many of those are in the aix or ppc specific codebase and could be addressed
>> by small adjustments.
>> A l
On Mon, 8 May 2023 10:29:56 GMT, Matthias Baesken wrote:
> After the harfbuzz 7.2 update we run into
>
> /linuxmuslx86_64/jdk-dev/src/java.desktop/share/native/libharfbuzz/OT/glyf/Glyph.hh:281:8:
> error: offset '4' outside bounds of constant string [-Werror=array-bounds]
> 281 | bool get_poi
On Thu, 4 May 2023 09:50:23 GMT, Axel Boldt-Christmas
wrote:
>>> I'm getting build warnings on all linux platforms with gcc-11.3.0:
>>>
>>> ```
>>> src/hotspot/share/gc/z/zDriver.cpp:84:13: error: In the GNU C Library,
>>> "minor" is defined
>>> by . For historical compatibility, it is
>>> c
On Wed, 3 May 2023 19:36:55 GMT, Stefan Karlsson wrote:
>> Hi all,
>>
>> Please review the implementation of Generational ZGC, which can be turned on
>> by adding -XX:+ZGenerational in addition to using -XX:+UseZGC. Generational
>> ZGC is a major rewrite of the non-generational ZGC version tha
On Wed, 3 May 2023 10:55:49 GMT, Stefan Karlsson wrote:
>> Hi all,
>>
>> Please review the implementation of Generational ZGC, which can be turned on
>> by adding -XX:+ZGenerational in addition to using -XX:+UseZGC. Generational
>> ZGC is a major rewrite of the non-generational ZGC version tha
On Wed, 3 May 2023 10:55:49 GMT, Stefan Karlsson wrote:
>> Hi all,
>>
>> Please review the implementation of Generational ZGC, which can be turned on
>> by adding -XX:+ZGenerational in addition to using -XX:+UseZGC. Generational
>> ZGC is a major rewrite of the non-generational ZGC version tha
On Fri, 21 Apr 2023 20:26:12 GMT, Roger Riggs wrote:
>> Define an internal jdk.internal.util.Architecture enumeration and static
>> methods to replace uses of the system property `os.arch`.
>> The enumeration values are defined to match those used in the build.
>> The initial values are: `X64, X
On Fri, 21 Apr 2023 08:40:49 GMT, Christoph Langer wrote:
> This is the plain fix for the currently observed error in GHA.
>
> Will handle the optional install of the MSVC toolchain in a separate item.
LGTM.
-
Marked as reviewed by mdoerr (Reviewer).
PR Review: https://git.openjd
On Mon, 17 Apr 2023 20:59:06 GMT, Roger Riggs wrote:
>> Define an internal jdk.internal.util.Architecture enumeration and static
>> methods to replace uses of the system property `os.arch`.
>> The enumeration values are defined to match those used in the build.
>> The initial values are: `X64, X
On Wed, 12 Apr 2023 17:31:49 GMT, Roger Riggs wrote:
>> Define an internal jdk.internal.util.Architecture enumeration and static
>> methods to replace uses of the system property `os.arch`.
>> The enumeration values are defined to match those used in the build.
>> The initial values are: `X64, X
On Tue, 11 Apr 2023 21:09:43 GMT, Roger Riggs wrote:
>> Define an internal jdk.internal.util.Architecture enumeration and static
>> methods to replace uses of the system property `os.arch`.
>> The enumeration values are defined to match those used in the build.
>> The initial values are: `X64, X
1 - 100 of 114 matches
Mail list logo
