On Fri, 18 Jul 2025 00:07:00 GMT, Alexander Matveev
wrote:
>> Re-submission of https://github.com/openjdk/jdk/pull/25314 after merge
>> conflict was resolved. Old PR will be closed.
>>
>> All comments are addressed from old PR. Merge conflict was significant, so
>> it is like new fix.
>>
>>
> Re-submission of https://github.com/openjdk/jdk/pull/25314 after merge
> conflict was resolved. Old PR will be closed.
>
> All comments are addressed from old PR. Merge conflict was significant, so it
> is like new fix.
>
> Fixed jpackage to produce valid Java runtimes based on description be
On Wed, 16 Jul 2025 22:26:51 GMT, Alexander Matveev
wrote:
>> Re-submission of https://github.com/openjdk/jdk/pull/25314 after merge
>> conflict was resolved. Old PR will be closed.
>>
>> All comments are addressed from old PR. Merge conflict was significant, so
>> it is like new fix.
>>
>>
> Re-submission of https://github.com/openjdk/jdk/pull/25314 after merge
> conflict was resolved. Old PR will be closed.
>
> All comments are addressed from old PR. Merge conflict was significant, so it
> is like new fix.
>
> Fixed jpackage to produce valid Java runtimes based on description be
On Thu, 17 Jul 2025 18:28:04 GMT, Chen Liang wrote:
>> On 32 bit platforms, when an access to long/double is aligned, it is
>> supported but not atomic. The original wording in
>> `MethodHandles::byteBufferViewVarHandle` sounds as if it is not supported at
>> all. We can fix that by borrowing
On Thu, 17 Jul 2025 18:00:31 GMT, Chen Liang wrote:
>> src/java.base/share/classes/java/lang/foreign/MemoryLayout.java line 281:
>>
>>> 279: * read write access modes for all {@code T}. On 32-bit platforms,
>>> access modes
>>> 280: * {@code get} and {@code set} for {@code long}, {@code d
On 11 Jul 2025, at 6:19, Chen Liang wrote:
> On Fri, 11 Jul 2025 13:05:09 GMT, Raffaello Giulietti
> wrote:
>
>>> src/java.base/share/classes/java/lang/invoke/MethodHandles.java line 4311:
>>>
4309: * access modes {@code get} and {@code set} for {@code
long}, {@code
4310
On Thu, 17 Jul 2025 12:35:54 GMT, Coleen Phillimore wrote:
>> src/hotspot/share/classfile/modules.cpp line 777:
>>
>>> 775: if (CDSConfig::is_using_full_module_graph()) {
>>> 776: precond(unnamed_module ==
>>> ClassLoaderDataShared::archived_boot_unnamed_module());
>>> 777: unnamed_mo
On Thu, 17 Jul 2025 18:28:04 GMT, Chen Liang wrote:
>> On 32 bit platforms, when an access to long/double is aligned, it is
>> supported but not atomic. The original wording in
>> `MethodHandles::byteBufferViewVarHandle` sounds as if it is not supported at
>> all. We can fix that by borrowing
On Thu, 17 Jul 2025 18:16:33 GMT, Chen Liang wrote:
> I think local arrays require more structural changes to the code, which might
> be why this patch did not include that change. However, note as said in
> #26355, such conversions are meaningful and would potentially allow
> performance boos
> Add `@Stable` to the static final arrays used in the Java port of FDLIBM.
Joe Darcy has updated the pull request incrementally with one additional commit
since the last revision:
Implement review feedback.
-
Changes:
- all: https://git.openjdk.org/jdk/pull/26341/files
- new
On Thu, 17 Jul 2025 18:28:04 GMT, Chen Liang wrote:
>> On 32 bit platforms, when an access to long/double is aligned, it is
>> supported but not atomic. The original wording in
>> `MethodHandles::byteBufferViewVarHandle` sounds as if it is not supported at
>> all. We can fix that by borrowing
On Thu, 17 Jul 2025 18:04:31 GMT, Raffaello Giulietti
wrote:
> The arrays at L.2257-2262 could be declared `static` and `@Stable` as well,
> and moved outside the method.
Right; those were the ones I was referring to when I wrote "Some small
refactorings could be used to make a few non-static
> In the `class` file format, a lot of the values are `u1` or `u2`; the
> Class-File API consistently model them with `int`. However, the API does not,
> in general, validate that int values passed to the factory methods are not
> out of the bounds as defined in the class file format. This patch
On Thu, 17 Jul 2025 19:06:25 GMT, Raffaello Giulietti
wrote:
>> src/java.base/share/classes/jdk/internal/math/FloatingDecimal.java line 1769:
>>
>>> 1767: * fields (> 550 lines).
>>> 1768: */
>>> 1769: private static BinaryToASCIIConverter
>>> getCompatBinaryToASCIIConverter(doub
On Thu, 17 Jul 2025 18:26:14 GMT, Naoto Sato wrote:
>> Raffaello Giulietti has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> Added comment to COMPAT static field.
>
> Good to see this enhancement, Raffaello. Are you planning to provide som
On Thu, 17 Jul 2025 18:26:14 GMT, Naoto Sato wrote:
>> Raffaello Giulietti has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> Added comment to COMPAT static field.
>
> Good to see this enhancement, Raffaello. Are you planning to provide som
> Sometimes, for version-specific feature access APIs, we wish to access the
> preview features of the current Java SE release. To reduce the impact of
> adding one preview-specific version on every site, we can add a constant
> modeling the preview features as a fake version.
Chen Liang has up
On Thu, 17 Jul 2025 17:58:51 GMT, Justin Lu wrote:
>> Raffaello Giulietti has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> Added comment to COMPAT static field.
>
> src/java.base/share/classes/jdk/internal/math/FloatingDecimal.java line 1
> Sometimes, for version-specific feature access APIs, we wish to access the
> preview features of the current Java SE release. To reduce the impact of
> adding one preview-specific version on every site, we can add a constant
> modeling the preview features as a fake version.
Chen Liang has up
On Thu, 10 Jul 2025 21:23:50 GMT, Joe Darcy wrote:
> > > What is the accuracy of the algorithm in ulps (units the last place)?
> > > The java.lang.Math specification has max error and various other accuracy
> > > requirements any implementation must meet.
> >
> >
> > 0.51 ulps
>
> Please add
> The goal of this PR is to implement an x86_64 intrinsic for
> java.lang.Math.sinh() using libm. There is a new set of micro-benchmarks are
> included to check the performance of specific input value ranges to help
> prevent regressions in the future.
>
> The command to run all range specific
On Thu, 17 Jul 2025 12:28:06 GMT, Raffaello Giulietti
wrote:
>> Align the behavior of `DecimalFormat` on `double`s with that of `Formatter`.
>
> Raffaello Giulietti has updated the pull request incrementally with one
> additional commit since the last revision:
>
> Added comment to COMPAT st
> On 32 bit platforms, when an access to long/double is aligned, it is
> supported but not atomic. The original wording in
> `MethodHandles::byteBufferViewVarHandle` sounds as if it is not supported at
> all. We can fix that by borrowing the improved specification from
> `MemoryLayout::varHandl
On Thu, 17 Jul 2025 18:18:21 GMT, Maurizio Cimadamore
wrote:
>> Chen Liang has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> avoid "non-atomic"
>
> src/java.base/share/classes/java/lang/foreign/MemoryLayout.java line 281:
>
>> 279: * re
On Thu, 17 Jul 2025 17:57:16 GMT, Chen Liang wrote:
>> On 32 bit platforms, when an access to long/double is aligned, it is
>> supported but not atomic. The original wording in
>> `MethodHandles::byteBufferViewVarHandle` sounds as if it is not supported at
>> all. We can fix that by borrowing
On Thu, 17 Jul 2025 17:44:04 GMT, Joe Darcy wrote:
>> Add `@Stable` to the static final arrays used in the Java port of FDLIBM.
>
> Joe Darcy has updated the pull request incrementally with one additional
> commit since the last revision:
>
> Respond to review feedback and update copyright.
On Thu, 17 Jul 2025 12:28:06 GMT, Raffaello Giulietti
wrote:
>> Align the behavior of `DecimalFormat` on `double`s with that of `Formatter`.
>
> Raffaello Giulietti has updated the pull request incrementally with one
> additional commit since the last revision:
>
> Added comment to COMPAT st
On Thu, 17 Jul 2025 17:44:04 GMT, Joe Darcy wrote:
>> Add `@Stable` to the static final arrays used in the Java port of FDLIBM.
>
> Joe Darcy has updated the pull request incrementally with one additional
> commit since the last revision:
>
> Respond to review feedback and update copyright.
On Wed, 16 Jul 2025 18:51:41 GMT, Joe Darcy wrote:
>> Add `@Stable` to the static final arrays used in the Java port of FDLIBM.
>
> The methods directly affected by this update are atan, exp, and sin, cos,
> tan. The sin, cos, and tan method are affected by the updates to
> KernelRemPio2 and ta
On Wed, 16 Jul 2025 09:28:28 GMT, Raffaello Giulietti
wrote:
>> Chen Liang has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> "may be non-atomic"
>
> src/java.base/share/classes/java/lang/foreign/MemoryLayout.java line 281:
>
>> 279: * r
> On 32 bit platforms, when an access to long/double is aligned, it is
> supported but not atomic. The original wording in
> `MethodHandles::byteBufferViewVarHandle` sounds as if it is not supported at
> all. We can fix that by borrowing the improved specification from
> `MemoryLayout::varHandl
> Add `@Stable` to the static final arrays used in the Java port of FDLIBM.
Joe Darcy has updated the pull request incrementally with one additional commit
since the last revision:
Respond to review feedback and update copyright.
-
Changes:
- all: https://git.openjdk.org/jdk/pu
On Thu, 17 Jul 2025 16:48:20 GMT, Naoto Sato wrote:
>> src/java.base/share/classes/java/io/Console.java line 51:
>>
>>> 49: * console. Regardless of how the virtual machine was created, it may
>>> not
>>> 50: * have a console if either the standard input or output stream is
>>> 51: * redirec
On Thu, 17 Jul 2025 15:32:32 GMT, cagliostro92 wrote:
>> Trivial PR to enhance Javadoc for the `Properties#list` method, which has
>> cost me some debugging time.
>
> cagliostro92 has updated the pull request incrementally with one additional
> commit since the last revision:
>
> 8358530: ad
On Wed, 16 Jul 2025 17:45:23 GMT, Ioi Lam wrote:
> Please review this documentation update, authored by @rose00 and originally
> pushed to the Leyden repo in [this
> PR](https://github.com/openjdk/leyden/pull/26), where more comments can be
> found regarding this update.
Marked as reviewed by
On Thu, 17 Jul 2025 10:58:30 GMT, Shaojin Wen wrote:
>> src/java.base/share/classes/java/lang/FdLibm.java line 815:
>>
>>> 813: */
>>> 814:
>>> 815: private static final int init_jk[] = {2, 3, 4, 6}; // initial
>>> value for jk
>>
>> Suggestion:
>>
>> @Stable private
The detection of catch builder arguments is not working for catch-all blocks.
Update this to track CP indices including 0 so we can more easily validate the
incoming ClassDesc are all non-primitive and there is no duplicate.
-
Commit messages:
- Formatting
- 8361638: java.lang.cla
On Thu, 17 Jul 2025 07:40:28 GMT, Alan Bateman wrote:
>> Naoto Sato has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Wording modification
>
> src/java.base/share/classes/java/io/Console.java line 51:
>
>> 49: * console. Regardless of ho
On Thu, 17 Jul 2025 14:29:08 GMT, Raffaello Giulietti
wrote:
> What is the thinking when an `@IntrinsicCandidate` method invokes another
> `@IntrinsicCandidate` method? Which part is responsible for the checks?
>
> For example, the Java code of `StringCoding.encodeISOArray0()` invokes
> `Stri
On Wed, 16 Jul 2025 17:42:45 GMT, Justin Lu wrote:
>> My bad, sorry. Fixed with 8d7e3d2fde65bd1e4ad85eca5ea93a430e2e8238
>
> Thanks for the changes. The current form seems reasonable to me, although
> others might have comments. I created the following CSR,
> [JDK-8362447](https://bugs.openjdk.
> Trivial PR to enhance Javadoc for the `Properties#list` method, which has
> cost me some debugging time.
cagliostro92 has updated the pull request incrementally with one additional
commit since the last revision:
8358530: adds oxford comma
-
Changes:
- all: https://git.openj
On Sun, 29 Jun 2025 20:43:56 GMT, Kim Barrett wrote:
>> This change makes java.nio no longer use jdk.internal.ref.Cleaner to manage
>> native memory for Direct-X-Buffers. Instead it uses bespoke PhantomReferences
>> and a dedicated ReferenceQueue. This differs from PR 22165, which proposed to
>>
On Thu, 17 Jul 2025 07:20:34 GMT, Volkan Yazici wrote:
>> Validate input in `java.lang.StringCoding` intrinsic Java wrappers, improve
>> their documentation, enhance the checks in the associated IR or assembly
>> code, and adapt them to cause VM crash on invalid input.
>>
>> ## Implementation
> Hi all,
>
> please review this change that implements (currently Draft) JEP: G1:
> Improve Application Throughput with a More Efficient Write-Barrier.
>
> The reason for posting this early is that this is a large change, and the JEP
> process is already taking very long with no end in sight
On Thu, 17 Jul 2025 07:20:34 GMT, Volkan Yazici wrote:
>> Validate input in `java.lang.StringCoding` intrinsic Java wrappers, improve
>> their documentation, enhance the checks in the associated IR or assembly
>> code, and adapt them to cause VM crash on invalid input.
>>
>> ## Implementation
On Thu, 10 Jul 2025 12:20:45 GMT, Volkan Yazici wrote:
>> Volkan Yazici has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Replace casting with `as_Region()` in `generate_string_range_check`
>
> src/java.base/share/classes/java/lang/StringC
On Thu, 17 Jul 2025 07:20:34 GMT, Volkan Yazici wrote:
>> Validate input in `java.lang.StringCoding` intrinsic Java wrappers, improve
>> their documentation, enhance the checks in the associated IR or assembly
>> code, and adapt them to cause VM crash on invalid input.
>>
>> ## Implementation
On Thu, 10 Jul 2025 12:18:25 GMT, Volkan Yazici wrote:
>> Volkan Yazici has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Replace casting with `as_Region()` in `generate_string_range_check`
>
> src/java.base/share/classes/java/lang/StringC
On Thu, 17 Jul 2025 07:20:34 GMT, Volkan Yazici wrote:
>> Validate input in `java.lang.StringCoding` intrinsic Java wrappers, improve
>> their documentation, enhance the checks in the associated IR or assembly
>> code, and adapt them to cause VM crash on invalid input.
>>
>> ## Implementation
On Wed, 9 Jul 2025 10:32:47 GMT, Pooja-DP wrote:
> Bug reference: https://bugs.openjdk.org/browse/JDK-8361697
>
> The following message is removed:
>
> `
> MSG_BundlerFailed=Error: Bundler "{1}" ({0}) failed to produce a package`
>
> Signed-off-by: Pooja.D.P1
This pull request has now been i
On Thu, 17 Jul 2025 13:41:06 GMT, Roger Riggs wrote:
>> Raffaello Giulietti has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> Added comment to COMPAT static field.
>
> src/java.base/share/classes/jdk/internal/math/FormattedFPDecimal.java l
On Thu, 17 Jul 2025 12:28:06 GMT, Raffaello Giulietti
wrote:
>> Align the behavior of `DecimalFormat` on `double`s with that of `Formatter`.
>
> Raffaello Giulietti has updated the pull request incrementally with one
> additional commit since the last revision:
>
> Added comment to COMPAT st
On Thu, 17 Jul 2025 12:29:39 GMT, Coleen Phillimore wrote:
>> The CDS full module graph is supposed to contain a snapshot of the boot
>> layer, which has 3 unnamed modules for the boot, platform and system class
>> loaders. Each unnamed module is represented by a `java.lang.Module` Java
>> obj
On Wed, 2 Jul 2025 00:18:28 GMT, Ioi Lam wrote:
> The CDS full module graph is supposed to contain a snapshot of the boot
> layer, which has 3 unnamed modules for the boot, platform and system class
> loaders. Each unnamed module is represented by a `java.lang.Module` Java
> object and a `Modu
On Tue, 8 Jul 2025 14:04:56 GMT, Daniel Fuchs wrote:
>> Hi,
>>
>> Please find here a PR for the implementation of [JEP 517: HTTP/3 for the
>> HTTP Client API](https://openjdk.org/jeps/517).
>>
>> The CSR can be viewed at [JDK-8350588: Implement JEP 517: HTTP/3 for the
>> HTTP Client API](http
> Align the behavior of `DecimalFormat` on `double`s with that of `Formatter`.
Raffaello Giulietti has updated the pull request incrementally with one
additional commit since the last revision:
Added comment to COMPAT static field.
-
Changes:
- all: https://git.openjdk.org/jdk/
On Thu, 17 Jul 2025 10:27:27 GMT, Raffaello Giulietti
wrote:
>> Add `@Stable` to the static final arrays used in the Java port of FDLIBM.
>
> src/java.base/share/classes/java/lang/FdLibm.java line 815:
>
>> 813: */
>> 814:
>> 815: private static final int init_jk[] = {2, 3, 4,
On Wed, 16 Jul 2025 04:53:04 GMT, Joe Darcy wrote:
> Add `@Stable` to the static final arrays used in the Java port of FDLIBM.
src/java.base/share/classes/java/lang/FdLibm.java line 457:
> 455: pio4 = 0x1.921fb54442d18p-1, // 7.85398163397448278999e-01
> 456: pio4lo=
On Wed, 16 Jul 2025 04:53:04 GMT, Joe Darcy wrote:
> Add `@Stable` to the static final arrays used in the Java port of FDLIBM.
The arrays at L.2257-2262 could be declared `static` and `@Stable` as well, and
moved outside the method.
src/java.base/share/classes/java/lang/FdLibm.java line 815:
Align the behavior of `DecimalFormat` on `double`s with that of `Formatter`.
-
Commit messages:
- Merge branch 'master' into 8362448
- 8362448: Make use of the Double.toString(double) algorithm in
java.text.DecimalFormat
- Remove some unused methods from FloatingDecimal.
- Rename
On Thu, 17 Jul 2025 07:20:34 GMT, Volkan Yazici wrote:
>> Validate input in `java.lang.StringCoding` intrinsic Java wrappers, improve
>> their documentation, enhance the checks in the associated IR or assembly
>> code, and adapt them to cause VM crash on invalid input.
>>
>> ## Implementation
On Fri, 11 Jul 2025 09:05:40 GMT, Christian Stein wrote:
> Please review the change to update to using jtreg 8.
>
> The primary change is to the `jib-profiles.js` file, which specifies the
> version of jtreg to use, for those systems that rely on this file. In
> addition, the requiredVersion h
On Thu, 17 Jul 2025 07:20:34 GMT, Volkan Yazici wrote:
>> Validate input in `java.lang.StringCoding` intrinsic Java wrappers, improve
>> their documentation, enhance the checks in the associated IR or assembly
>> code, and adapt them to cause VM crash on invalid input.
>>
>> ## Implementation
On Mon, 14 Jul 2025 22:39:56 GMT, Naoto Sato wrote:
>> This accompanies the fix for
>> [JDK-8361613](https://bugs.openjdk.org/browse/JDK-8361613), which restricts
>> `System.console()` to return a `Console` instance only when both standard
>> input and output are connected to a terminal. The c
On Thu, 17 Jul 2025 07:04:00 GMT, Tobias Hartmann wrote:
>> @TobiHartmann, this change results in the following compiler error:
>>
>>
>> /home/vy/.../src/hotspot/share/opto/library_call.cpp:958:35: error: invalid
>> conversion from 'Node*' to 'RegionNode*' [-fpermissive]
>> 958 | generate_
> Validate input in `java.lang.StringCoding` intrinsic Java wrappers, improve
> their documentation, enhance the checks in the associated IR or assembly
> code, and adapt them to cause VM crash on invalid input.
>
> ## Implementation notes
>
> The goal of the associated umbrella issue
> [JDK-8
On Thu, 17 Jul 2025 04:35:01 GMT, Volkan Yazici wrote:
>> src/hotspot/share/opto/library_call.cpp line 963:
>>
>>> 961:
>>> 962: if (bailout->req() > 1) {
>>> 963: if (halt) {
>>
>> Toggle to force a VM crash to be used to surface intrinsic Java wrappers
>> failing to spot invalid input
On Thu, 17 Jul 2025 06:33:43 GMT, Brian Burkhalter wrote:
> Hi all,
>
> This pull request contains a backport of commit
> [be0161a8](https://github.com/openjdk/jdk/commit/be0161a8e63096f3a21ce6ea1e055ee1c4ed63ad)
> from the [openjdk/jdk](https://git.openjdk.org/jdk) repository.
>
> Th
69 matches
Mail list logo
