On Mon, 27 Nov 2023 20:04:54 GMT, Erik Joelsson wrote:
>>> What's the issue with this? Full name on my profile "Galder Zamarreño".
>>
>> I don't know really. Could be a bug with the Skara bots that choke on the ñ
>> (but I think we've had users with accented characters in their username
>>
On Fri, 3 Nov 2023 23:42:03 GMT, Joe Darcy wrote:
> Time to start making preparations for JDK 23.
Hotspot change is trivially fine, but too insignificant to hit the Approve
button.
Thanks
-
PR Review: https://git.openjdk.org/jdk/pull/16505#pullrequestreview-1752152672
On Mon, 27 Nov 2023 23:44:25 GMT, Sandhya Viswanathan
wrote:
>> Not listed here: https://oca.opensource.oracle.com/?ojr=contributors
>
> Yes, Vamsi is part of Intel Java team. He also has the author status
> (https://openjdk.org/census#sparasa).
@sviswa7 I am asking about the copyright holder
On Mon, 27 Nov 2023 16:43:09 GMT, Andrew Haley wrote:
>> Apparently the situation is this: If your build machine happens to have SVE,
>> then you will get SVE support in the vmath library. The SVE support will be
>> used during runtime if the machine you run on has SVE support.
>>
>> If your
On Sat, 18 Nov 2023 01:21:09 GMT, Srinivas Vamsi Parasa
wrote:
>> The goal is to develop faster sort routines for x86_64 CPUs by taking
>> advantage of AVX2 instructions. This enhancement provides an order of
>> magnitude speedup for Arrays.sort() using int, long, float and double arrays.
>>
On Tue, 28 Nov 2023 00:04:55 GMT, Sandhya Viswanathan
wrote:
>> Srinivas Vamsi Parasa 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 request contains 11
>>
On Tue, 21 Nov 2023 15:14:28 GMT, Dalibor Topic wrote:
>> src/java.base/linux/native/libsimdsort/avx2-32bit-qsort.hpp line 3:
>>
>>> 1: /*
>>> 2: * Copyright (c) 2021, 2023, Intel Corporation. All rights reserved.
>>> 3: * Copyright (c) 2021 Serge Sans Paille. All rights reserved.
>>
>> Is
On Fri, 3 Nov 2023 23:42:03 GMT, Joe Darcy wrote:
> Time to start making preparations for JDK 23.
Marked as reviewed by iris (Reviewer).
-
PR Review: https://git.openjdk.org/jdk/pull/16505#pullrequestreview-1751551968
On Mon, 27 Nov 2023 14:50:30 GMT, Magnus Ihse Bursie wrote:
> What's the issue with this? Full name on my profile "Galder Zamarreño".
I've dug into this a bit and here is what I've found. The letter
On Fri, 3 Nov 2023 23:42:03 GMT, Joe Darcy wrote:
> Time to start making preparations for JDK 23.
Nothing exception in this batch of start-of-release updates. Clean local
testing results on tier 1.
The symbol files correspond to JDK 22 build 25 and will be updated with
subsequent builds as
On Fri, 3 Nov 2023 23:42:03 GMT, Joe Darcy wrote:
> Time to start making preparations for JDK 23.
Changes requested by liach (Author).
src/java.base/share/classes/jdk/internal/classfile/Classfile.java line 1:
> 1: /*
`latestMajorVersion` below should be updated to return `JAVA_23_VERSION` as
On Fri, 3 Nov 2023 23:52:45 GMT, Chen Liang wrote:
>> Time to start making preparations for JDK 23.
>
> src/java.base/share/classes/jdk/internal/classfile/Classfile.java line 1:
>
>> 1: /*
>
> `latestMajorVersion` below should be updated to return `JAVA_23_VERSION` as
> well.
Good catch;
Time to start making preparations for JDK 23.
-
Commit messages:
- Add symbol files for JDK 22 build 25.
- Merge branch 'master' into JDK-8319413
- Merge branch 'master' into JDK-8319413
- Adjust expected release date.
- Fix omission in Classfile.java
- JDK-8319413: Start of
On Mon, 27 Nov 2023 14:12:11 GMT, Magnus Ihse Bursie wrote:
> For some reason, we have not been consistent with using spaces around the
> assignment operators (`:=` and `=`) in spec.gmk.in. This has annoyed me for a
> long time.
>
> When making this change, I noticed that there are a lot of
On Mon, 27 Nov 2023 15:05:20 GMT, Magnus Ihse Bursie wrote:
>> For some reason, we have not been consistent with using spaces around the
>> assignment operators (`:=` and `=`) in spec.gmk.in. This has annoyed me for
>> a long time.
>>
>> When making this change, I noticed that there are a lot
On Mon, 27 Nov 2023 15:05:20 GMT, Magnus Ihse Bursie wrote:
>> For some reason, we have not been consistent with using spaces around the
>> assignment operators (`:=` and `=`) in spec.gmk.in. This has annoyed me for
>> a long time.
>>
>> When making this change, I noticed that there are a lot
On Mon, 27 Nov 2023 15:22:32 GMT, Magnus Ihse Bursie wrote:
> In fact, I am not even sure why it seems to the PR author to be a good idea
> to let the default be dependent on the build machine at all. My personal
> opinion is that it would be better to select either "SVE enabled" or "SVE
>
On Mon, 27 Nov 2023 14:43:09 GMT, Magnus Ihse Bursie wrote:
> In theory, you can run "make install" on a newly built JDK to have it
> installed in /usr/local/bin, just as with many system tools.
>
> This is not recommended to do. You might mess up your boot JDK, and Java
> installations
On Mon, 27 Nov 2023 14:43:09 GMT, Magnus Ihse Bursie wrote:
> In theory, you can run "make install" on a newly built JDK to have it
> installed in /usr/local/bin, just as with many system tools.
>
> This is not recommended to do. You might mess up your boot JDK, and Java
> installations
On Mon, 27 Nov 2023 15:11:32 GMT, Andrew Haley wrote:
>> You still need to separate out the SVE detection from the libsleef code, and
>> provide a way to enable/disable it from the configure command line. It is
>> not okay to auto-detect if features should be turned on or off by default,
>>
On Mon, 27 Nov 2023 14:59:23 GMT, Magnus Ihse Bursie wrote:
> You still need to separate out the SVE detection from the libsleef code, and
> provide a way to enable/disable it from the configure command line.
Why? I don't think this should be a build-time option at all, because it puts
the
On Mon, 27 Nov 2023 10:28:45 GMT, Andrew Haley wrote:
>> We have to use this c-compiler option to build out the SVE ABIs (e.g.
>> `svfloat32_t sinfx_u10sve(svfloat32_t input)`) in `libvmath.so`. Without
>> this option, at build time, all the sve related featues like `arm_sve.h /
>>
> For some reason, we have not been consistent with using spaces around the
> assignment operators (`:=` and `=`) in spec.gmk.in. This has annoyed me for a
> long time.
>
> When making this change, I noticed that there are a lot of late evaluation
> assignments (= instead of :=) that should
On Thu, 23 Nov 2023 15:08:42 GMT, Magnus Ihse Bursie wrote:
> The OpenJDK build system does not support building when the source code
> resides on a path that contains a space. This requirement is documented in
> the build instructions but not enforced by the configure script.
>
> This change
On Mon, 27 Nov 2023 08:30:47 GMT, Galder Zamarreño wrote:
> What's the issue with this? Full name on my profile "Galder Zamarreño".
I don't know really. Could be a bug with the Skara bots that choke on the ñ
(but I think we've had users with accented characters in their username before,
so
In theory, you can run "make install" on a newly built JDK to have it installed
in /usr/local/bin, just as with many system tools.
This is not recommended to do. You might mess up your boot JDK, and Java
installations generally do not work like this. (Instead, you are likely to have
symbolic
On Thu, 23 Nov 2023 15:08:42 GMT, Magnus Ihse Bursie wrote:
> The OpenJDK build system does not support building when the source code
> resides on a path that contains a space. This requirement is documented in
> the build instructions but not enforced by the configure script.
>
> This change
For some reason, we have not been consistent with using spaces around the
assignment operators (`:=` and `=`) in spec.gmk.in. This has annoyed me for a
long time.
When making this change, I noticed that there are a lot of late evaluation
assignments (= instead of :=) that should not be there.
On Tue, 21 Nov 2023 21:40:49 GMT, intrigus-lgtm wrote:
> May I ask, why you all are so fixated on using `branches-ignore:`? Can you
> not simply add another job, that ignore pushes if the branch name has a
> specific format and if the repository is "openjdk/jdk"?
I think you misunderstand how
On Mon, 27 Nov 2023 07:38:28 GMT, Galder Zamarreño wrote:
>> FYI @theRealAph
>>
>> It includes a couple of commits to integrate with Capstone v6 while still
>> working with Capstone v5 and before:
>> * `CAPSTONE_ARCH` for aarch64 is now `CS_ARCH_AARCH64` instead of
>> `CS_ARCH_ARM64`. See
On Mon, 27 Nov 2023 01:06:21 GMT, Xiaohong Gong wrote:
>> make/autoconf/lib-vmath.m4 line 94:
>>
>>> 92: # Check the ARM SVE feature
>>> 93: SVE_CFLAGS="-march=armv8-a+sve"
>>> 94:
>>
>> What's this about? We're building a standard binary, and all SVE detection
>> is to
> Classfile API is an internal library under package `jdk.internal.classfile`
> in JDK 21.
> This pull request turns the Classfile API into a preview feature and moves it
> into `java.lang.classfile`.
> It repackages all uses across JDK and tests and adds lots of missing Javadoc.
>
> This PR
> Classfile API is an internal library under package `jdk.internal.classfile`
> in JDK 21.
> This pull request turns the Classfile API into a preview feature and moves it
> into `java.lang.classfile`.
> It repackages all uses across JDK and tests and adds lots of missing Javadoc.
>
> This PR
On Mon, 27 Nov 2023 06:12:01 GMT, Galder Zamarreño wrote:
>> Galder Zamarreño has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> 8320533: Comment undef call
>
> Hmmm, had to change the title.
> ⚠️ @galderz the full name on your profile
On Mon, 27 Nov 2023 07:38:28 GMT, Galder Zamarreño wrote:
>> FYI @theRealAph
>>
>> It includes a couple of commits to integrate with Capstone v6 while still
>> working with Capstone v5 and before:
>> * `CAPSTONE_ARCH` for aarch64 is now `CS_ARCH_AARCH64` instead of
>> `CS_ARCH_ARM64`. See
35 matches
Mail list logo
