On Wed, 13 Mar 2024 01:02:50 GMT, Alex Menkov wrote:
>> RecordComponent class has _attributes_count field.
>> The only user of the field is JvmtiClassFileReconstituter. Incorrect value
>> of the field causes producing incorrect data for Record attribute.
>> Parsing Record attribute
On Wed, 13 Mar 2024 01:02:50 GMT, Alex Menkov wrote:
>> RecordComponent class has _attributes_count field.
>> The only user of the field is JvmtiClassFileReconstituter. Incorrect value
>> of the field causes producing incorrect data for Record attribute.
>> Parsing Record attribute
On Tue, 12 Dec 2023 03:58:03 GMT, Vicente Romero wrote:
>> Vicente Romero has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> removing comment
>
> src/java.base/share/classes/java/lang/reflect/Executable.java line 343:
>
>> 341:
> Adding a table that maps JDK versions and corresponding CLDR releases as an
> implNote. A draft CSR has also been created.
Naoto Sato has updated the pull request incrementally with one additional
commit since the last revision:
Addressing further comments
-
Changes:
- all:
> RecordComponent class has _attributes_count field.
> The only user of the field is JvmtiClassFileReconstituter. Incorrect value of
> the field causes producing incorrect data for Record attribute.
> Parsing Record attribute ClassFileParser skips unknown attributes and may
> skip
On Tue, 12 Mar 2024 19:41:03 GMT, Justin Lu wrote:
>> Naoto Sato has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Reflects review comments
>
> src/java.base/share/classes/java/util/spi/LocaleServiceProvider.java line 144:
>
>> 142: *
On Tue, 12 Mar 2024 19:09:27 GMT, Shaojin Wen wrote:
>> The current BigDecimal(String) constructor calls String#toCharArray, which
>> has a memory allocation.
>>
>>
>> public BigDecimal(String val) {
>> this(val.toCharArray(), 0, val.length()); // allocate char[]
>> }
>>
>>
>> When the
On Tue, 12 Mar 2024 19:22:25 GMT, Chad Rakoczy wrote:
>> Fix for [8325621](https://bugs.openjdk.org/browse/JDK-8325621)
>>
>> Updates jspawnhelper to check that JDK version and jspawnhelper version are
>> the same. Updates test to include check for version. Also tested manually by
>>
On Tue, 12 Mar 2024 10:12:18 GMT, Viktor Klang wrote:
>> Please review this patch that:
>> 1. Implemented `forEach` to optimize for 1 or 2 element collections.
>> 2. Implemented `spliterator` to optimize for a single element.
>>
>> The default implementations for multiple-element immutable
On Tue, 12 Mar 2024 18:50:38 GMT, Naoto Sato wrote:
>> Adding a table that maps JDK versions and corresponding CLDR releases as an
>> implNote. A draft CSR has also been created.
>
> Naoto Sato has updated the pull request incrementally with one additional
> commit since the last revision:
>
This change enables to run JspawnhelperProtocol.java on MacOS.
In addition to GHA , the test has been run on macos and linux.
Test report is stored in
build/macosx-x86_64-server-fastdebug/test-results/jtreg_test_jdk_java_lang_ProcessBuilder_JspawnhelperProtocol_java
On Thu, 7 Mar 2024 23:31:46 GMT, Justin Lu wrote:
> Please review this PR which is a trivial update to the IANA sub tag registry
> to version 2024-03-07. Tests pass as expected after update.
>
> Associated announcement ->
>
On Tue, 12 Mar 2024 18:50:38 GMT, Naoto Sato wrote:
>> Adding a table that maps JDK versions and corresponding CLDR releases as an
>> implNote. A draft CSR has also been created.
>
> Naoto Sato has updated the pull request incrementally with one additional
> commit since the last revision:
>
On Tue, 12 Mar 2024 18:50:38 GMT, Naoto Sato wrote:
>> Adding a table that maps JDK versions and corresponding CLDR releases as an
>> implNote. A draft CSR has also been created.
>
> Naoto Sato has updated the pull request incrementally with one additional
> commit since the last revision:
>
> Fix for [8325621](https://bugs.openjdk.org/browse/JDK-8325621)
>
> Updates jspawnhelper to check that JDK version and jspawnhelper version are
> the same. Updates test to include check for version. Also tested manually by
> replacing jspawnhelper with incorrect version to confirm that check
On Tue, 5 Mar 2024 19:56:58 GMT, Weijun Wang wrote:
>> This code change adds an alternative implementation of user-based
>> authorization `Subject` APIs that doesn't depend on Security Manager APIs.
>> Depending on if the Security Manager is allowed, the methods store the
>> current subject
> The current BigDecimal(String) constructor calls String#toCharArray, which
> has a memory allocation.
>
>
> public BigDecimal(String val) {
> this(val.toCharArray(), 0, val.length()); // allocate char[]
> }
>
>
> When the length is greater than 18, create a char[]
>
>
> boolean
> Adding a table that maps JDK versions and corresponding CLDR releases as an
> implNote. A draft CSR has also been created.
Naoto Sato has updated the pull request incrementally with one additional
commit since the last revision:
Reflects review comments
-
Changes:
- all:
On Tue, 12 Mar 2024 18:13:28 GMT, Joe Wang wrote:
> Irrelevant to this doc change, I happen to notice some of the
> jdk``-suported-locales docs might have not been updated. For
> example,
> https://www.oracle.com/java/technologies/javase/jdk20-suported-locales.html
> had "CLDR release 39"
On Mon, 11 Mar 2024 19:12:33 GMT, Chad Rakoczy wrote:
>> Fix for [8325621](https://bugs.openjdk.org/browse/JDK-8325621)
>>
>> Updates jspawnhelper to check that JDK version and jspawnhelper version are
>> the same. Updates test to include check for version. Also tested manually by
>>
On Tue, 12 Mar 2024 16:26:48 GMT, Naoto Sato wrote:
> Adding a table that maps JDK versions and corresponding CLDR releases as an
> implNote. A draft CSR has also been created.
Irrelevant to this doc change, I happen to notice some of the
jdk``-suported-locales docs might have not been
> Classes in the `java.lang.ref` package would benefit from an update to bring
> the spec in line with how the VM already behaves. The changes would focus on
> _happens-before_ edges at some key points during reference processing.
>
> A couple key things we want to be able to say are:
> -
On Mon, 11 Mar 2024 19:12:33 GMT, Chad Rakoczy wrote:
>> Fix for [8325621](https://bugs.openjdk.org/browse/JDK-8325621)
>>
>> Updates jspawnhelper to check that JDK version and jspawnhelper version are
>> the same. Updates test to include check for version. Also tested manually by
>>
On Sun, 10 Mar 2024 05:50:33 GMT, Eirik Bjørsnøs wrote:
> Please review this PR which removes the 19 deprecated `xxObject*` alias
> methods from `jdk.internal.misc.Unsafe`.
>
> These methods were added in JDK-8213043 (JDK 12), presumably to allow
> `jsr166.jar` to be used across JDK versions.
On Sun, 10 Mar 2024 13:47:06 GMT, Eirik Bjørsnøs wrote:
>> Please review this PR which removes the 19 deprecated `xxObject*` alias
>> methods from `jdk.internal.misc.Unsafe`.
>>
>> These methods were added in JDK-8213043 (JDK 12), presumably to allow
>> `jsr166.jar` to be used across JDK
On Wed, 6 Mar 2024 17:54:57 GMT, Joe Darcy wrote:
> The atan2 and hypot cases added would fail for a particular test library that
> has errors in the millions of ulps for those inputs, rather than the small
> number of ulps specified for the error.
This pull request has now been integrated.
Adding a table that maps JDK versions and corresponding CLDR releases as an
implNote. A draft CSR has also been created.
-
Commit messages:
- initial commit
Changes: https://git.openjdk.org/jdk/pull/18243/files
Webrev: https://webrevs.openjdk.org/?repo=jdk=18243=00
Issue:
On Tue, 12 Mar 2024 15:24:21 GMT, Magnus Ihse Bursie wrote:
> Please re-test.
Hi Magnus, thanks for the adjustments. I reenabled your patch in our
build/test queue .
-
PR Comment: https://git.openjdk.org/jdk/pull/18172#issuecomment-1992009593
On Tue, 12 Mar 2024 13:51:28 GMT, Magnus Ihse Bursie wrote:
>> test/jdk/java/foreign/CallGeneratorHelper.java line 216:
>>
>>> 214: if (header) {
>>> 215: System.out.println(
>>> 216: "#include \"export.h\"\n"
>>
>> We don't generate these header files any
> 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
> the old xlc toolchain is no longer supported, and should be
On Mon, 11 Mar 2024 12:27:08 GMT, Joachim Kern wrote:
>> Magnus Ihse Bursie has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> Revert SEARCH_PATH changes
>
> make/autoconf/toolchain.m4 line 940:
>
>> 938: if test "x$OPENJDK_TARGET_OS" =
On Mon, 11 Mar 2024 12:44:55 GMT, Matthias Baesken wrote:
>> Magnus Ihse Bursie has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> Revert SEARCH_PATH changes
>
> With this change added, currently configure fails
>
>
> checking for
On Tue, 12 Mar 2024 15:15:27 GMT, Magnus Ihse Bursie wrote:
>> make/autoconf/toolchain.m4 line 409:
>>
>>> 407: #Target: powerpc-ibm-aix7.2.0.0
>>> 408: #Thread model: posix
>>> 409: #InstalledDir: /opt/IBM/openxlC/17.1.0/bin
>>
>> Please correct:
>> IBM Open XL C/C++
On Mon, 11 Mar 2024 09:14:27 GMT, Joachim Kern wrote:
>> Magnus Ihse Bursie has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> Revert SEARCH_PATH changes
>
> make/autoconf/toolchain.m4 line 409:
>
>> 407: #Target:
On Mon, 11 Mar 2024 13:45:46 GMT, Joachim Kern wrote:
>> OK this was a flaw in my introduction of clang toolchain for AIX. The
>> intention was to keep the xlc options in form of their clang counterparts. I
>> will try with a corrected version for clang on AIX and will come back to you.
>
>
On Tue, 12 Mar 2024 15:07:15 GMT, Magnus Ihse Bursie wrote:
>>> Is Open XL C/C++ considered a compiler or more akin to a development
>>> environment like Xcode is for macOS? Depending on which, we could just say
>>> clang is the compiler for AIX without needing to say that Open XL is
>>>
On Tue, 12 Mar 2024 15:04:56 GMT, Magnus Ihse Bursie wrote:
>> Is Open XL C/C++ considered a compiler or more akin to a development
>> environment like Xcode is for macOS? Depending on which, we could just say
>> clang is the compiler for AIX without needing to say that Open XL is treated
>>
On Mon, 11 Mar 2024 09:30:20 GMT, Julian Waters wrote:
> Is Open XL C/C++ considered a compiler or more akin to a development
> environment like Xcode is for macOS? Depending on which, we could just say
> clang is the compiler for AIX without needing to say that Open XL is treated
> like
> 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
> the old xlc toolchain is no longer supported, and should be
On Tue, 27 Feb 2024 15:23:09 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
>>
On Tue, 12 Mar 2024 13:07:26 GMT, Shaojin Wen wrote:
>> The current BigDecimal(String) constructor calls String#toCharArray, which
>> has a memory allocation.
>>
>>
>> public BigDecimal(String val) {
>> this(val.toCharArray(), 0, val.length()); // allocate char[]
>> }
>>
>>
>> When the
In cases where the compiler needs to unbox a `long`, `float`, `double` and then
run the exactness check, we were getting a crash. While the selector value is
always boxed, the type (which controls the execution flow) was not, because the
`selectorType` was wrong. This PR addresses this bug.
On Mon, 11 Mar 2024 13:06:55 GMT, Erik Joelsson wrote:
>> Why the rm? Because jlink refuses to run if the output dir already exists.
>
> I don't see a race. The `rm` was there in the original code and is no scarier
> in the modified version. The jdk image is constructed by a combination of
>
On Mon, 11 Mar 2024 20:04:48 GMT, Roger Riggs wrote:
>> Chad Rakoczy has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Code cleanup
>
> make/modules/java.base/Launcher.gmk line 85:
>
>> 83: -DVERSION_INTERIM=$(VERSION_INTERIM)
On Tue, 12 Mar 2024 13:07:26 GMT, Shaojin Wen wrote:
>> The current BigDecimal(String) constructor calls String#toCharArray, which
>> has a memory allocation.
>>
>>
>> public BigDecimal(String val) {
>> this(val.toCharArray(), 0, val.length()); // allocate char[]
>> }
>>
>>
>> When the
On Mon, 11 Mar 2024 06:57:58 GMT, Alan Bateman wrote:
> Good cleanup.
Thanks!
-
PR Comment: https://git.openjdk.org/jdk/pull/18135#issuecomment-1991712859
On Mon, 11 Mar 2024 02:31:02 GMT, David Holmes wrote:
>> Magnus Ihse Bursie has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> Update line number for dereference_null in TestDwarf
>
>
On Mon, 11 Mar 2024 06:57:42 GMT, Alan Bateman wrote:
> > test/jdk/java/lang/Thread/jni/AttachCurrentThread/libImplicitAttach.c was
> > missing an export. This had not been discovered before since that file was
> > not compiled on Windows.
> It's a Linux/macOS specific test so it wasn't
On Fri, 8 Mar 2024 18:12:40 GMT, Jorn Vernee wrote:
>> Magnus Ihse Bursie has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> Update line number for dereference_null in TestDwarf
>
> test/jdk/java/foreign/CallGeneratorHelper.java line 216:
> The current BigDecimal(String) constructor calls String#toCharArray, which
> has a memory allocation.
>
>
> public BigDecimal(String val) {
> this(val.toCharArray(), 0, val.length()); // allocate char[]
> }
>
>
> When the length is greater than 18, create a char[]
>
>
> boolean
On Tue, 12 Mar 2024 09:41:46 GMT, Claes Redestad wrote:
>> Shaojin Wen has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> easier to compare
>
> Sorry, when I got pinged in here the earlier comments didn't render and I
> missed the
> The current BigDecimal(String) constructor calls String#toCharArray, which
> has a memory allocation.
>
>
> public BigDecimal(String val) {
> this(val.toCharArray(), 0, val.length()); // allocate char[]
> }
>
>
> When the length is greater than 18, create a char[]
>
>
> boolean
On Mon, 11 Mar 2024 17:17:21 GMT, Joe Darcy wrote:
>> The atan2 and hypot cases added would fail for a particular test library
>> that has errors in the millions of ulps for those inputs, rather than the
>> small number of ulps specified for the error.
>
> Joe Darcy has updated the pull
On Tue, 12 Mar 2024 10:34:33 GMT, Shaojin Wen wrote:
>> The current BigDecimal(String) constructor calls String#toCharArray, which
>> has a memory allocation.
>>
>>
>> public BigDecimal(String val) {
>> this(val.toCharArray(), 0, val.length()); // allocate char[]
>> }
>>
>>
>> When the
On Mon, 11 Mar 2024 17:17:21 GMT, Joe Darcy wrote:
>> The atan2 and hypot cases added would fail for a particular test library
>> that has errors in the millions of ulps for those inputs, rather than the
>> small number of ulps specified for the error.
>
> Joe Darcy has updated the pull
On Tue, 12 Mar 2024 10:34:33 GMT, Shaojin Wen wrote:
>> The current BigDecimal(String) constructor calls String#toCharArray, which
>> has a memory allocation.
>>
>>
>> public BigDecimal(String val) {
>> this(val.toCharArray(), 0, val.length()); // allocate char[]
>> }
>>
>>
>> When the
On Tue, 12 Mar 2024 10:34:33 GMT, Shaojin Wen wrote:
>> The current BigDecimal(String) constructor calls String#toCharArray, which
>> has a memory allocation.
>>
>>
>> public BigDecimal(String val) {
>> this(val.toCharArray(), 0, val.length()); // allocate char[]
>> }
>>
>>
>> When the
Moving array construction within BigInteger.implMultiplyToLen intrinsic
candidate to its caller simplifies the intrinsic implementation in JIT compiler.
-
Commit messages:
- Simplify BigInteger.implMultiplyToLen intrinsic
Changes: https://git.openjdk.org/jdk/pull/18226/files
> The current BigDecimal(String) constructor calls String#toCharArray, which
> has a memory allocation.
>
>
> public BigDecimal(String val) {
> this(val.toCharArray(), 0, val.length()); // allocate char[]
> }
>
>
> When the length is greater than 18, create a char[]
>
>
> boolean
> The current BigDecimal(String) constructor calls String#toCharArray, which
> has a memory allocation.
>
>
> public BigDecimal(String val) {
> this(val.toCharArray(), 0, val.length()); // allocate char[]
> }
>
>
> When the length is greater than 18, create a char[]
>
>
> boolean
On Wed, 20 Sep 2023 04:52:31 GMT, Chen Liang wrote:
> Please review this patch that:
> 1. Implemented `forEach` to optimize for 1 or 2 element collections.
> 2. Implemented `spliterator` to optimize for a single element.
>
> The default implementations for multiple-element immutable collections
On Tue, 12 Mar 2024 06:18:27 GMT, Shaojin Wen wrote:
>> The current BigDecimal(String) constructor calls String#toCharArray, which
>> has a memory allocation.
>>
>>
>> public BigDecimal(String val) {
>> this(val.toCharArray(), 0, val.length()); // allocate char[]
>> }
>>
>>
>> When the
On Sun, 10 Mar 2024 13:47:06 GMT, Eirik Bjørsnøs wrote:
>> Please review this PR which removes the 19 deprecated `xxObject*` alias
>> methods from `jdk.internal.misc.Unsafe`.
>>
>> These methods were added in JDK-8213043 (JDK 12), presumably to allow
>> `jsr166.jar` to be used across JDK
> The current BigDecimal(String) constructor calls String#toCharArray, which
> has a memory allocation.
>
>
> public BigDecimal(String val) {
> this(val.toCharArray(), 0, val.length()); // allocate char[]
> }
>
>
> When the length is greater than 18, create a char[]
>
>
> boolean
On Thu, 25 Jan 2024 21:35:45 GMT, Sergey wrote:
> The feature allows to extract a private field value in a single expression,
> like so:
>
> object.getClass().getDeclaredField().setAccessible().get(object)
src/java.base/share/classes/java/lang/reflect/Field.java line 184:
> 182: *
65 matches
Mail list logo
