Re: RFR: 8331942: On Linux aarch64, CDS archives should be using 64K alignment by default

On Wed, 8 May 2024 15:14:16 GMT, Thomas Stuefe wrote: > On Linux aarch64, a JVM may encounter three different page sizes: 4K, 64K, > and (when run on Mac M1 hardware) 16K. > > Since forgetting to specify `--enable-compatible-cds-alignment` is a common > error that is only noticed when running

Withdrawn: 8311846: Resolve duplicate 'Thread' related symbols with JDK static linking

On Wed, 17 Jan 2024 00:14:58 GMT, Jiangli Zhou wrote: > Please review this PR with a simple solution for resolving duplicate `Thread` > symbol issue. In https://github.com/openjdk/jdk/pull/14808 comments, there > was an alternative suggestion to redefine the symbol at build time, such as >

RFR: 8331952: --enable-compatible-cds-alignment should be enabled by default

--enable-compatible-cds-alignment should be enabled by default - Commit messages: - --enable-compatible-cds-alignment should be enabled by default Changes: https://git.openjdk.org/jdk/pull/19150/files Webrev: https://webrevs.openjdk.org/?repo=jdk=19150=00 Issue:

Integrated: 8331541: [i386] linking with libjvm.so fails after JDK-8283326

On Thu, 2 May 2024 08:23:38 GMT, Vladimir Petko wrote: > Hi, > > The `.type _SafeFetch32_impl,@function` symbol declaration contains a > spurious underscore causing an undefined symbol in libjvm.so. > > I am not sure about change in default flags. I have removed the flag that > allows

Re: RFR: 8311302: Allow for jlinking a custom runtime without packaged modules being present [v26]

On Tue, 7 May 2024 16:52:12 GMT, Severin Gehwolf wrote: >> Please review this patch which adds a jlink mode to the JDK which doesn't >> need the packaged modules being present. A.k.a run-time image based jlink. >> Fundamentally this patch adds an option to use `jlink` even though your JDK >>

Integrated: 8331939: Add custom hook for TestImage

On Wed, 8 May 2024 14:03:48 GMT, Erik Joelsson wrote: > We need a custom hook in TestImage.gmk to modify behavior when building with > custom source. This pull request has now been integrated. Changeset: 0d1216c7 Author:Erik Joelsson URL:

Integrated: 8331886: Allow markdown src file overrides

On Wed, 8 May 2024 01:02:41 GMT, Erik Joelsson wrote: > For c, c++ and java source files, we have a built in system for letting more > specific files override if there are multiple files with the same name found, > by letting the first found file with a given name override any later found >

RE: JDK-8170635 -- adding a base library to java

Thanks for the reply @Magnus Ihse Bursie Is there any example of PRs which create such libraries that I can refer to ? Is OSAL similar to how os.cpp is defined and respective platforms implement them ? From: Magnus Ihse Bursie Date: Tuesday, 7 May 2024 at

Re: RFR: 8331942: On Linux aarch64, CDS archives should be using 64K alignment by default

On Wed, 8 May 2024 17:01:26 GMT, Andrew Haley wrote: > This is obviously correct. Otherwise, the CDS archive will only work if the > JDK happens to have been built on a machine with greater or equal page size. > > Does the default `compatible-cds-alignment=false` make any sense anywhere on >

Re: RFR: 8331939: Add custom hook for TestImage

On Wed, 8 May 2024 14:03:48 GMT, Erik Joelsson wrote: > We need a custom hook in TestImage.gmk to modify behavior when building with > custom source. Marked as reviewed by mikael (Reviewer). - PR Review: https://git.openjdk.org/jdk/pull/19139#pullrequestreview-2046326105

Re: RFR: 8312425: [vectorapi] AArch64: Optimize vector math operations with SLEEF [v6]

> Hi, > Can you help to review the patch? > This pr is based on previous work and discussion in [pr > 16234](https://github.com/openjdk/jdk/pull/16234), [pr > 18294](https://github.com/openjdk/jdk/pull/18294). > > Compared with previous prs, the major change in this pr is to integrate the >

Re: RFR: 8312425: [vectorapi] AArch64: Optimize vector math operations with SLEEF [v2]

On Tue, 9 Apr 2024 20:10:36 GMT, Mikael Vidstedt wrote: >> Hamlin Li has updated the pull request incrementally with two additional >> commits since the last revision: >> >> - disable unused-function warnings; add log msg >> - minor > > Thank you for the update and for working on this in

Re: RFR: 8312425: [vectorapi] AArch64: Optimize vector math operations with SLEEF [v5]

> Hi, > Can you help to review the patch? > This pr is based on previous work and discussion in [pr > 16234](https://github.com/openjdk/jdk/pull/16234), [pr > 18294](https://github.com/openjdk/jdk/pull/18294). > > Compared with previous prs, the major change in this pr is to integrate the >

Re: RFR: 8331942: On Linux aarch64, CDS archives should be using 64K alignment by default

On Wed, 8 May 2024 15:14:16 GMT, Thomas Stuefe wrote: > On Linux aarch64, a JVM may encounter three different page sizes: 4K, 64K, > and (when run on Mac M1 hardware) 16K. > > Since forgetting to specify `--enable-compatible-cds-alignment` is a common > error that is only noticed when running

Re: RFR: 8311302: Allow for jlinking a custom runtime without packaged modules being present [v25]

On Thu, 4 Apr 2024 20:56:55 GMT, Magnus Ihse Bursie wrote: >> Severin Gehwolf has updated the pull request incrementally with three >> additional commits since the last revision: >> >> - Use shorter name for the build tool >> - Review feedback from Erik J. >> - Remove dependency on CDS

RFR: 8331942: On Linux aarch64, CDS archives should be using 64K alignment by default

On Linux aarch64, a JVM may encounter three different page sizes: 4K, 64K, and (when run on Mac M1 hardware) 16K. Since forgetting to specify `--enable-compatible-cds-alignment` is a common error that is only noticed when running the produced JVM on hardware with different page size, we

Re: RFR: 8311302: Allow for jlinking a custom runtime without packaged modules being present [v26]

On Tue, 7 May 2024 16:52:12 GMT, Severin Gehwolf wrote: >> Please review this patch which adds a jlink mode to the JDK which doesn't >> need the packaged modules being present. A.k.a run-time image based jlink. >> Fundamentally this patch adds an option to use `jlink` even though your JDK >>

Re: RFR: 8331886: Allow markdown src file overrides [v2]

On Wed, 8 May 2024 14:29:18 GMT, Erik Joelsson wrote: >> For c, c++ and java source files, we have a built in system for letting >> more specific files override if there are multiple files with the same name >> found, by letting the first found file with a given name override any later >>

Re: RFR: 8331921: Hotspot assembler files should use common logic to setup exported functions

On Wed, 8 May 2024 13:30:59 GMT, Magnus Ihse Bursie wrote: > As seen in [JDK-8331541](https://bugs.openjdk.org/browse/JDK-8331541), if we > are not consistently setting all assembler directives correctly, we can get > errors that are not detected by the linker. > > We should stop duplicating

RFR: 8331921: Hotspot assembler files should use common logic to setup exported functions

As seen in [JDK-8331541](https://bugs.openjdk.org/browse/JDK-8331541), if we are not consistently setting all assembler directives correctly, we can get errors that are not detected by the linker. We should stop duplicating this code and create a unified macro to properly setup functions, and

Re: RFR: 8331886: Allow markdown src file overrides [v2]

> For c, c++ and java source files, we have a built in system for letting more > specific files override if there are multiple files with the same name found, > by letting the first found file with a given name override any later found > files with that name. This is typically used for OS

RFR: 8331939: Add custom hook for TestImage

We need a custom hook in TestImage.gmk to modify behavior when building with custom source. - Commit messages: - JDK-8331939 Changes: https://git.openjdk.org/jdk/pull/19139/files Webrev: https://webrevs.openjdk.org/?repo=jdk=19139=00 Issue:

Re: RFR: 8331541: [i386] linking with libjvm.so fails after JDK-8283326

On Thu, 2 May 2024 08:23:38 GMT, Vladimir Petko wrote: > Hi, > > The `.type _SafeFetch32_impl,@function` symbol declaration contains a > spurious underscore causing an undefined symbol in libjvm.so. > > I am not sure about change in default flags. I have removed the flag that > allows

Re: RFR: 8331541: [i386] linking with libjvm.so fails after JDK-8283326

On Thu, 2 May 2024 08:23:38 GMT, Vladimir Petko wrote: > Hi, > > The `.type _SafeFetch32_impl,@function` symbol declaration contains a > spurious underscore causing an undefined symbol in libjvm.so. > > I am not sure about change in default flags. I have removed the flag that > allows

Re: RFR: 8331541: [i386] linking with libjvm.so fails after JDK-8283326

On Thu, 2 May 2024 08:23:38 GMT, Vladimir Petko wrote: > Hi, > > The `.type _SafeFetch32_impl,@function` symbol declaration contains a > spurious underscore causing an undefined symbol in libjvm.so. > > I am not sure about change in default flags. I have removed the flag that > allows

Re: RFR: 8331886: Allow markdown src file overrides

On Wed, 8 May 2024 01:02:41 GMT, Erik Joelsson wrote: > For c, c++ and java source files, we have a built in system for letting more > specific files override if there are multiple files with the same name found, > by letting the first found file with a given name override any later found >

Re: RFR: 8331886: Allow markdown src file overrides

On Wed, 8 May 2024 01:02:41 GMT, Erik Joelsson wrote: > For c, c++ and java source files, we have a built in system for letting more > specific files override if there are multiple files with the same name found, > by letting the first found file with a given name override any later found >

Re: RFR: 8311302: Allow for jlinking a custom runtime without packaged modules being present [v26]

On Tue, 7 May 2024 16:52:12 GMT, Severin Gehwolf wrote: >> Please review this patch which adds a jlink mode to the JDK which doesn't >> need the packaged modules being present. A.k.a run-time image based jlink. >> Fundamentally this patch adds an option to use `jlink` even though your JDK >>

Re: RFR: 8331541: [i386] linking with libjvm.so fails after JDK-8283326

On Thu, 2 May 2024 08:23:38 GMT, Vladimir Petko wrote: > Hi, > > The `.type _SafeFetch32_impl,@function` symbol declaration contains a > spurious underscore causing an undefined symbol in libjvm.so. > > I am not sure about change in default flags. I have removed the flag that > allows