This is a follow-up on
[JDK-8328680](https://bugs.openjdk.org/browse/JDK-8328680), making the same
kind of cleanup to java.base. Some code needed more special treatment here, so
there is some additional effects outside of the modules/java.base directory.
-
Commit messages:
- Fix
On Fri, 22 Mar 2024 17:09:16 GMT, Magnus Ihse Bursie wrote:
> This is a follow-up on
> [JDK-8328680](https://bugs.openjdk.org/browse/JDK-8328680), making the same
> kind of cleanup to java.base. Some code needed more special treatment here,
> so there is some additional effects outside of the
Dear Team
Can you please help me with this?
*2023-10-24 12:16:57.027 java[97952:198365] WARNING: Secure coding is
automatically enabled for restorable state! However, not on all supported
macOS versions of this application. Opt-in to secure coding explicitly by
implementing
On Fri, 22 Mar 2024 10:29:36 GMT, Robbin Ehn wrote:
>>> What is the relevance of SVE support at build time? Should it matter what
>>> the build machine is?
>>
>> My understanding is that we need a compiler that supports
>> `-march=armv8-a+sve`; otherwise we can't build the redirect library
On Fri, 22 Mar 2024 12:42:04 GMT, Magnus Ihse Bursie wrote:
> > Ah, it'll only be the redirect library that's compiled with
> > -march=armv8-a+sve Forget that.
>
> But that raises an interesting question. What happens if you try to load a
> library compiled with `-march=armv8-a+sve` on a
On Fri, 15 Mar 2024 13:58:05 GMT, Hamlin Li wrote:
>> Hi,
>> Can you help to review this patch?
>> Thanks
>>
>> This is a continuation of work based on [1] by @XiaohongGong, most work was
>> done in that pr. In this new pr, just rebased the code in [1], then added
>> some minor changes
On Fri, 22 Mar 2024 10:29:36 GMT, Robbin Ehn wrote:
> > > What is the relevance of SVE support at build time? Should it matter what
> > > the build machine is?
> >
> >
> > My understanding is that we need a compiler that supports
> > `-march=armv8-a+sve`; otherwise we can't build the
> Noticed this while fixing other GHA issues.
>
> We pass build JDK to cross-compilation jobs, which makes them dependent on
> Linux-x64 builds. But we only build hotspot in all those jobs, so AFAICS
> there is no need for build JDK, and therefore no need for the dependency.
> Untying
On Thu, 21 Mar 2024 15:33:21 GMT, Aleksey Shipilev wrote:
> Debian "unstable" is currently undergoing t64 (hello, Y2038) transition,
> which breaks "sid" repo that we use for debootstrapping RISC-V very often.
> This is seen across multiple repositories, and requires everyone to look
>
On Thu, 21 Mar 2024 15:33:21 GMT, Aleksey Shipilev wrote:
> Debian "unstable" is currently undergoing t64 (hello, Y2038) transition,
> which breaks "sid" repo that we use for debootstrapping RISC-V very often.
> This is seen across multiple repositories, and requires everyone to look
>
On Thu, 21 Mar 2024 11:49:11 GMT, Magnus Ihse Bursie wrote:
> This is the first step of several, in which I will clean up the native
> compilation code as used by modules. In this first step `java.base`,
> `java.deskop`, `jdk.accessibility` and `jdk.jpackage` are left out, since
> they
On Thu, 21 Mar 2024 06:58:43 GMT, Robbin Ehn wrote:
>> Hi, please consider.
>>
>> [8327045](https://bugs.openjdk.org/browse/JDK-8327045) hide these symbols.
>> Tested with gcc and clang, and llvm and binutils backend.
>>
>> I didn't find any use of the "DLL_ENTRY", so I removed it.
>>
>>
On Fri, 22 Mar 2024 10:16:44 GMT, Magnus Ihse Bursie wrote:
>> This is the first step of several, in which I will clean up the native
>> compilation code as used by modules. In this first step `java.base`,
>> `java.deskop`, `jdk.accessibility` and `jdk.jpackage` are left out, since
>> they
On Thu, 21 Mar 2024 15:33:21 GMT, Aleksey Shipilev wrote:
> Debian "unstable" is currently undergoing t64 (hello, Y2038) transition,
> which breaks "sid" repo that we use for debootstrapping RISC-V very often.
> This is seen across multiple repositories, and requires everyone to look
>
On Fri, 22 Mar 2024 11:43:34 GMT, Magnus Ihse Bursie wrote:
> > is this how you want us to export these symbols?
>
> Close but no cigar. :-)
>
> Use `JNIEXPORT` instead, that is properly defined for this purpose and works
> on all compilers. You will need to also add:
>
> ```
> #include
On Fri, 22 Mar 2024 12:31:53 GMT, Andrew Haley wrote:
> Ah, it'll only be the redirect library that's compiled with
> -march=armv8-a+sve Forget that.
But that raises an interesting question. What happens if you try to load a
library compiled with `-march=armv8-a+sve` on a non-SVE system? Is
On Fri, 22 Mar 2024 10:29:36 GMT, Robbin Ehn wrote:
>>> What is the relevance of SVE support at build time? Should it matter what
>>> the build machine is?
>>
>> My understanding is that we need a compiler that supports
>> `-march=armv8-a+sve`; otherwise we can't build the redirect library
On Fri, 22 Mar 2024 10:49:13 GMT, Julian Waters wrote:
>> bot-keep-alive
>>
>> @TheShermanTanker Did you understand the remaining changes that Phil has
>> requested? Do you think you'll be able to fix this?
>
> @magicus Phil doesn't seem to be responding to my queries, I'm not too sure
>
On Sat, 20 Jan 2024 00:40:40 GMT, Phil Race wrote:
>> Julian Waters has updated the pull request with a new target base due to a
>> merge or a rebase. The pull request now contains 79 commits:
>>
>> - Merge branch 'openjdk:master' into patch-10
>> - Merge branch 'openjdk:master' into
On Fri, 22 Mar 2024 12:31:01 GMT, Andrew Haley wrote:
> > > What is the relevance of SVE support at build time? Should it matter what
> > > the build machine is?
> >
> >
> > My understanding is that we need a compiler that supports
> > `-march=armv8-a+sve`; otherwise we can't build the
On Fri, 15 Mar 2024 13:58:05 GMT, Hamlin Li wrote:
>> Hi,
>> Can you help to review this patch?
>> Thanks
>>
>> This is a continuation of work based on [1] by @XiaohongGong, most work was
>> done in that pr. In this new pr, just rebased the code in [1], then added
>> some minor changes
On Fri, 3 Nov 2023 02:39:26 GMT, Julian Waters wrote:
>> src/java.desktop/windows/native/libawt/windows/awt_PrintJob.cpp line 61:
>>
>>> 59:
>>> 60: jfieldID AwtPrintDialog::pageID;
>>> 61:
>>
>> where and why did this come from ?
>
> This came from below, all I did was move it up and out of
On Sat, 20 Jan 2024 00:32:19 GMT, Phil Race wrote:
>> Julian Waters has updated the pull request with a new target base due to a
>> merge or a rebase. The pull request now contains 79 commits:
>>
>> - Merge branch 'openjdk:master' into patch-10
>> - Merge branch 'openjdk:master' into
On Sun, 3 Dec 2023 15:37:47 GMT, Julian Waters wrote:
>> src/java.desktop/windows/native/libawt/windows/awt_Frame.cpp line 1641:
>>
>>> 1639: }
>>> 1640: }
>>> 1641:
>>
>> A possible improvement later (and for a future RFE) would be to use RAII for
>> deletion and then get rid of
On Wed, 20 Mar 2024 06:38:59 GMT, Julian Waters wrote:
>> We should set the -permissive- flag for the Microsoft Visual C compiler, as
>> was requested by the now backed out
>> [JDK-8241499](https://bugs.openjdk.org/browse/JDK-8241499). Doing so makes
>> the Visual C compiler much less
On Wed, 20 Mar 2024 18:55:38 GMT, Jan Lahoda wrote:
>> This is a patch that:
>> a) upgrades the JLine inside the JDK to 3.25.1
>> b) since the new version of JLine has a FFM backend, our custom native
>> backends are removed, and replaced with the FFM backend
>>
>> Some changes had to be made
On Wed, 20 Mar 2024 18:55:38 GMT, Jan Lahoda wrote:
>> This is a patch that:
>> a) upgrades the JLine inside the JDK to 3.25.1
>> b) since the new version of JLine has a FFM backend, our custom native
>> backends are removed, and replaced with the FFM backend
>>
>> Some changes had to be made
On Wed, 20 Mar 2024 18:55:38 GMT, Jan Lahoda wrote:
>> This is a patch that:
>> a) upgrades the JLine inside the JDK to 3.25.1
>> b) since the new version of JLine has a FFM backend, our custom native
>> backends are removed, and replaced with the FFM backend
>>
>> Some changes had to be made
On Wed, 20 Mar 2024 18:55:38 GMT, Jan Lahoda wrote:
>> This is a patch that:
>> a) upgrades the JLine inside the JDK to 3.25.1
>> b) since the new version of JLine has a FFM backend, our custom native
>> backends are removed, and replaced with the FFM backend
>>
>> Some changes had to be made
On Thu, 21 Mar 2024 06:58:43 GMT, Robbin Ehn wrote:
>> Hi, please consider.
>>
>> [8327045](https://bugs.openjdk.org/browse/JDK-8327045) hide these symbols.
>> Tested with gcc and clang, and llvm and binutils backend.
>>
>> I didn't find any use of the "DLL_ENTRY", so I removed it.
>>
>>
On Fri, 22 Mar 2024 10:25:33 GMT, Robbin Ehn wrote:
> is this how you want us to export these symbols?
Close but no cigar. :-)
Use `JNIEXPORT` instead, that is properly defined for this purpose and works on
all compilers. You will need to also add:
#include "jni.h"
If this is not picked
On Fri, 22 Mar 2024 11:38:25 GMT, Magnus Ihse Bursie wrote:
> I can give a spoiler to what the upcoming JDK_LIBS rewrite will do.
>
> Currently, if you want to link with e.g. `jli`, this is what you need to do:
>
> ```
> $(eval $(call SetupJdkLibrary, BUILD_LIBMYLIB, \
> NAME := mylib, \
>
On Fri, 22 Mar 2024 10:16:44 GMT, Magnus Ihse Bursie wrote:
>> This is the first step of several, in which I will clean up the native
>> compilation code as used by modules. In this first step `java.base`,
>> `java.deskop`, `jdk.accessibility` and `jdk.jpackage` are left out, since
>> they
On Fri, 22 Mar 2024 10:47:30 GMT, Julian Waters wrote:
>> Magnus Ihse Bursie has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> Fix indentation
>
> make/common/JdkNativeCompilation.gmk line 190:
>
>> 188: $1_SRC_HEADER_FLAGS +=
On Fri, 22 Mar 2024 10:43:40 GMT, Julian Waters wrote:
>> Magnus Ihse Bursie has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> Fix indentation
>
> make/autoconf/libraries.m4 line 174:
>
>> 172:
>> 173: JDKLIB_LIBS="$BASIC_JDKLIB_LIBS"
On Fri, 15 Mar 2024 13:58:05 GMT, Hamlin Li wrote:
>> Hi,
>> Can you help to review this patch?
>> Thanks
>>
>> This is a continuation of work based on [1] by @XiaohongGong, most work was
>> done in that pr. In this new pr, just rebased the code in [1], then added
>> some minor changes
On Mon, 18 Mar 2024 15:55:15 GMT, Magnus Ihse Bursie wrote:
>> Julian Waters has updated the pull request with a new target base due to a
>> merge or a rebase. The pull request now contains 84 commits:
>>
>> - Merge branch 'openjdk:master' into patch-10
>> - awt_Window.cpp
>> -
On Fri, 22 Mar 2024 10:16:44 GMT, Magnus Ihse Bursie wrote:
>> This is the first step of several, in which I will clean up the native
>> compilation code as used by modules. In this first step `java.base`,
>> `java.deskop`, `jdk.accessibility` and `jdk.jpackage` are left out, since
>> they
On Fri, 22 Mar 2024 10:16:44 GMT, Magnus Ihse Bursie wrote:
>> This is the first step of several, in which I will clean up the native
>> compilation code as used by modules. In this first step `java.base`,
>> `java.deskop`, `jdk.accessibility` and `jdk.jpackage` are left out, since
>> they
On Fri, 22 Mar 2024 08:51:47 GMT, Andrew Haley wrote:
>> @theRealAph Are you saying that bundling the source code of libsleef is a
>> hard requirement from your side to accept this code into the JDK?
>>
>> I'm not against it, I just want to understand what we're talking about here.
>>
>> In
On Fri, 22 Mar 2024 10:22:54 GMT, Magnus Ihse Bursie wrote:
> > What is the relevance of SVE support at build time? Should it matter what
> > the build machine is?
>
> My understanding is that we need a compiler that supports
> `-march=armv8-a+sve`; otherwise we can't build the redirect
On Thu, 21 Mar 2024 06:58:43 GMT, Robbin Ehn wrote:
>> Hi, please consider.
>>
>> [8327045](https://bugs.openjdk.org/browse/JDK-8327045) hide these symbols.
>> Tested with gcc and clang, and llvm and binutils backend.
>>
>> I didn't find any use of the "DLL_ENTRY", so I removed it.
>>
>>
On Fri, 15 Mar 2024 16:58:06 GMT, Andrew Haley wrote:
> What is the relevance of SVE support at build time? Should it matter what the
> build machine is?
My understanding is that we need a compiler that supports `-march=armv8-a+sve`;
otherwise we can't build the redirect library properly. But
> This is the first step of several, in which I will clean up the native
> compilation code as used by modules. In this first step `java.base`,
> `java.deskop`, `jdk.accessibility` and `jdk.jpackage` are left out, since
> they require more work. The changes in the remaining modules are trivial
On Thu, 21 Mar 2024 17:56:12 GMT, Erik Joelsson wrote:
> Looks good, just found some indentation levels not conforming to the
> convention and as you are fixing style, I pointed them out.
Absolutely! Fixing style was one of the points here. It's funny, really, I've
been staring at this code
On Thu, 21 Mar 2024 15:43:28 GMT, Magnus Ihse Bursie wrote:
>>> > The problem I see is that J. Random Java User has no way to know if SLEEF
>>> > is making their program faster without running benchmarks. They'll put
>>> > SLEEF somewhere and hope that Java uses it.
>>>
>>> Please kindly
On Thu, 21 Mar 2024 15:33:21 GMT, Aleksey Shipilev wrote:
> Debian "unstable" is currently undergoing t64 (hello, Y2038) transition,
> which breaks "sid" repo that we use for debootstrapping RISC-V very often.
> This is seen across multiple repositories, and requires everyone to look
>
47 matches
Mail list logo
