> This PR proposes to implement `hashCode()` and `equals()` methods for
> implementations of `PathElement`.
>
> In doing so, the previous `PathElementImpl` was removed and replaced in favor
> of distinct `record` implementations, each reflecting its own path element
> selection type. This also
On Thu, 1 Feb 2024 22:19:26 GMT, Joe Darcy wrote:
>> The restricted javac warning is disabled for java.base, but could be enabled
>> by suppressing the warning in a handful of files.
>
> Joe Darcy has updated the pull request incrementally with one additional
> commit since the last revision:
On Fri, 2 Feb 2024 06:55:19 GMT, Magnus Ihse Bursie wrote:
>> Similar to [JDK-8318696](https://bugs.openjdk.org/browse/JDK-8318696), we
>> should use -D_FILE_OFFSET_BITS=64, and not -D_LARGEFILE64_SOURCE in the JDK
>> native libraries.
>
> Magnus Ihse Bursie has updated the pull request
On Fri, 2 Feb 2024 06:55:19 GMT, Magnus Ihse Bursie wrote:
>> Similar to [JDK-8318696](https://bugs.openjdk.org/browse/JDK-8318696), we
>> should use -D_FILE_OFFSET_BITS=64, and not -D_LARGEFILE64_SOURCE in the JDK
>> native libraries.
>
> Magnus Ihse Bursie has updated the pull request
On Fri, 2 Feb 2024 06:55:19 GMT, Magnus Ihse Bursie wrote:
>> Similar to [JDK-8318696](https://bugs.openjdk.org/browse/JDK-8318696), we
>> should use -D_FILE_OFFSET_BITS=64, and not -D_LARGEFILE64_SOURCE in the JDK
>> native libraries.
>
> Magnus Ihse Bursie has updated the pull request
On Thu, 1 Feb 2024 15:54:40 GMT, Matthias Baesken wrote:
>>> @MBaesken So my fix in
>>> [25c691d](https://github.com/openjdk/jdk/pull/17538/commits/25c691df823eb9d9db1451637f28d59dd9508386)
>>> did not help? Maybe then it is some other system library that drags in
>>> `fcntl.h`; I assumed it
> Similar to [JDK-8318696](https://bugs.openjdk.org/browse/JDK-8318696), we
> should use -D_FILE_OFFSET_BITS=64, and not -D_LARGEFILE64_SOURCE in the JDK
> native libraries.
Magnus Ihse Bursie has updated the pull request incrementally with one
additional commit since the last revision:
Add
On Thu, 1 Feb 2024 17:21:23 GMT, Joe Darcy wrote:
> I just suggest double-checking on the current maintenance procedures for the
> java.util.concurrent code.
@jddarcy Any idea how to do that? I tried searching for JSR-166 and
java.util.concurrent, but all I could find was talk about a
On Fri, 2 Feb 2024 04:47:22 GMT, Quan Anh Mai wrote:
>>> I don't think Lilliput will relax the array alignment to below 4 bytes
>>> since the array length needs to be aligned at that.
>>
>> HI @merykitty
>>
>> Lilliput wiki mention about shrinking object header below 4 bytes in future.
>>
On Fri, 2 Feb 2024 04:51:33 GMT, jmehrens wrote:
> Circling back to "the case where many keys exist in both maps". What are your
> thoughts on some optimized variant/refactoring of:
int s = Math.max(m.size() - this.size(), 1);
Calling `Math.max` is unnecessary here. Its ok if `s` ends up
On Thu, 1 Feb 2024 22:19:26 GMT, Joe Darcy wrote:
>> The restricted javac warning is disabled for java.base, but could be enabled
>> by suppressing the warning in a handful of files.
>
> Joe Darcy has updated the pull request incrementally with one additional
> commit since the last revision:
On Sat, 27 Jan 2024 21:58:05 GMT, Joshua Cao wrote:
>> src/java.base/share/classes/java/util/HashMap.java line 503:
>>
>>> 501: */
>>> 502: final void putMapEntries(Map m, boolean
>>> evict) {
>>> 503: int s = Math.max(size() + m.size(), m.size());
>>
>> If we decide this
On Fri, 2 Feb 2024 03:34:38 GMT, Jatin Bhateja wrote:
>> Hi @sviswa7 , I have rolled back to originally proposed solution.
>
>> I don't think Lilliput will relax the array alignment to below 4 bytes since
>> the array length needs to be aligned at that.
>
> HI @merykitty
>
> Lilliput wiki
On Mon, 4 Dec 2023 17:46:18 GMT, Tom Rodriguez wrote:
> This slightly increases the wait for reference processing to complete to
> accommodate long Xcomp compile times. Testing is underway.
This pull request has been closed without being integrated.
-
PR:
On Wed, 31 Jan 2024 21:29:08 GMT, Sandhya Viswanathan
wrote:
>> Jatin Bhateja has refreshed the contents of this pull request, and previous
>> commits have been removed. Incremental views are not available.
>
> src/hotspot/cpu/x86/c2_MacroAssembler_x86.cpp line 1613:
>
>> 1611: vpand(xtmp,
On Thu, 1 Feb 2024 16:25:52 GMT, Jatin Bhateja wrote:
>> I guess the fact that the Java objects are 8 byte alignment padded and the
>> alignment being done at lines 1609-1611 and 1616-1621 somehow takes care of
>> this.
>
> Hi @sviswa7 , I have rolled back to originally proposed solution.
> I
On Thu, 1 Feb 2024 23:02:59 GMT, Justin Lu wrote:
>> Archie Cobbs has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Fix misspelling in comment.
>
> test/jdk/java/text/Format/MessageFormat/MessageFormatToPatternTest.java line
> 26:
>
>>
> Please consider this fix to ensure that going from `MessageFormat` to pattern
> string via `toPattern()` and then back via `new MessageFormat()` results in a
> format that is equivalent to the original.
>
> The quoting and escaping rules for `MessageFormat` pattern strings are really
>
On Thu, 1 Feb 2024 23:57:24 GMT, Naoto Sato wrote:
>> Archie Cobbs has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Fix misspelling in comment.
>
> src/java.base/share/classes/java/text/MessageFormat.java line 1675:
>
>> 1673:
Modify the specification verbiage of `java.io.RandomAccessFile.setLength` to
account for the effect of the method on the file offset as returned by
`getFilePointer`.
-
Commit messages:
- 8325152: Clarify specification of java.io.RandomAccessFile.setLength
Changes:
On Thu, 1 Feb 2024 12:22:10 GMT, Maurizio Cimadamore
wrote:
>> My expectation is the risk is small, but of course non-zero. These tests can
>> be expensive to run so i was trying balance the risk without increasing test
>> execution times.
>>
>> I could strengthen the comment from:
>>
>>
On Tue, 30 Jan 2024 18:28:32 GMT, Archie Cobbs wrote:
>> Please consider this fix to ensure that going from `MessageFormat` to
>> pattern string via `toPattern()` and then back via `new MessageFormat()`
>> results in a format that is equivalent to the original.
>>
>> The quoting and escaping
> The implementation of method `VectorSpecies::fromMemorySegment`, in
> `AbstractSpecies::fromMemorySegment`, neglects to perform bounds checks on
> the offset argument when the method is compiled by C2 (bounds checks are
> performed when interpreted and by C1).
>
> This is an oversight and
On Tue, 30 Jan 2024 18:28:32 GMT, Archie Cobbs wrote:
>> Please consider this fix to ensure that going from `MessageFormat` to
>> pattern string via `toPattern()` and then back via `new MessageFormat()`
>> results in a format that is equivalent to the original.
>>
>> The quoting and escaping
Implementing "loose matching" of space separators in both
`java.time.format.DateTimeFormatter` and `java.text.DateFormat` on lenient
parsing. This will effectively fix the NNBSP issues on parsing time with am/pm
markers introduced with CLDR version 42
On Thu, 1 Feb 2024 11:57:04 GMT, Magnus Ihse Bursie wrote:
> This is a follow-up on
> [JDK-8324053](https://bugs.openjdk.org/browse/JDK-8324053). I have run the
> bin/blessed-modifier-order.sh on the entire code base, and manually checked
> the result. I have reverted all but these trivial
On Tue, 30 Jan 2024 21:19:27 GMT, Justin Lu wrote:
> Please review this PR and [CSR](https://bugs.openjdk.org/browse/JDK-8314822)
> which allows for the _Format_ segment of a ChoiceFormat pattern to use the
> ChoiceFormat Relational symbols without the need to escape them using quotes.
>
On Thu, 1 Feb 2024 22:01:49 GMT, Jorn Vernee wrote:
> This looks good to me. It will be easier to find where we are doing
> restricted operations like this.
Right; follows the recommended approach of minimizing the scope of the
SuppressWarnings annotations too. Thanks.
-
PR
> The restricted javac warning is disabled for java.base, but could be enabled
> by suppressing the warning in a handful of files.
Joe Darcy has updated the pull request incrementally with one additional commit
since the last revision:
Add comment highlighting restricted method calls.
On Thu, 1 Feb 2024 21:10:48 GMT, Joe Darcy wrote:
> The restricted javac warning is disabled for java.base, but could be enabled
> by suppressing the warning in a handful of files.
This looks good to me. It will be easier to find where we are doing restricted
operations like this.
On Thu, 1 Feb 2024 20:10:29 GMT, Jorn Vernee wrote:
>> See the JBS issue for an extended problem description.
>>
>> This patch changes the specification and implementation of
>> `MethodHandles::byteArrayViewVarHandle`,
>> `MethodHandles::byteBufferViewVarHandle`, `ByteBuffer::alignedSlice`,
On Fri, 5 Jan 2024 15:17:13 GMT, Adam Sotona wrote:
> `java.lang.classfile.CodeBuilder` contains more than 230 API methods.
> Existing ClassFile API use cases proved the concept one big CodeBuilder is
> comfortable. However there are some redundancies, glitches in the naming
> conventions,
On Wed, 31 Jan 2024 01:17:07 GMT, Brian Burkhalter wrote:
> Align the specification of `Unsafe.allocateMemory` with its implementation
> and with the specification of `Unsafe.reallocateMemory`.
CSR created.
-
PR Comment:
On Thu, 1 Feb 2024 21:10:48 GMT, Joe Darcy wrote:
> The restricted javac warning is disabled for java.base, but could be enabled
> by suppressing the warning in a handful of files.
Marked as reviewed by erikj (Reviewer).
-
PR Review:
On Wed, 30 Aug 2023 22:35:43 GMT, Naoto Sato wrote:
>> This is stemming from the PR: https://github.com/openjdk/jdk/pull/14211
>> where aggressive GC can cause NPE in `BaseLocale$Key` class. I refactored
>> the in-house cache with WeakHashMap, and removed the Key class as it is no
>> longer
On Wed, 31 Jan 2024 22:24:14 GMT, Justin Lu wrote:
> Please review this PR and [CSR](https://bugs.openjdk.org/browse/JDK-8319344)
> which adds MessageFormat pattern support for the following subformats:
> ListFormat, CompactNumberFormat, and DateTimeFormatter. This change is
> intended to
The restricted javac warning is disabled for java.base, but could be enabled by
suppressing the warning in a handful of files.
-
Commit messages:
- JDK-8325148: Enable restricted javac warning in java.base
Changes: https://git.openjdk.org/jdk/pull/17677/files
Webrev:
> See the JBS issue for an extended problem description.
>
> This patch changes the specification and implementation of
> `MethodHandles::byteArrayViewVarHandle`,
> `MethodHandles::byteBufferViewVarHandle`, `ByteBuffer::alignedSlice`, and
> `ByteBuffer::alignmentOffset` to weaken the
On Wed, 15 Nov 2023 22:46:03 GMT, Jorn Vernee wrote:
> See the JBS issue for an extended problem description.
>
> This patch changes the specification and implementation of
> `MethodHandles::byteArrayViewVarHandle`,
> `MethodHandles::byteBufferViewVarHandle`, `ByteBuffer::alignedSlice`, and
On Thu, 1 Feb 2024 17:01:11 GMT, Roger Riggs wrote:
> lgtm
Thanks @RogerRiggs.
-
PR Comment: https://git.openjdk.org/jdk/pull/17643#issuecomment-1922050326
On Wed, 6 Dec 2023 14:20:14 GMT, Claes Redestad wrote:
> https://bugs.openjdk.org/browse/JDK-8215017 removed the only use of
> `StringUTF16::equals`. At the time I did some performance verification
> focused on x86 showing that simplifying and only using `StringLatin1::equals`
> was either
On Thu, 1 Feb 2024 11:57:04 GMT, Magnus Ihse Bursie wrote:
> This is a follow-up on
> [JDK-8324053](https://bugs.openjdk.org/browse/JDK-8324053). I have run the
> bin/blessed-modifier-order.sh on the entire code base, and manually checked
> the result. I have reverted all but these trivial
On Thu, 1 Feb 2024 11:57:04 GMT, Magnus Ihse Bursie wrote:
> This is a follow-up on
> [JDK-8324053](https://bugs.openjdk.org/browse/JDK-8324053). I have run the
> bin/blessed-modifier-order.sh on the entire code base, and manually checked
> the result. I have reverted all but these trivial
On Wed, 31 Jan 2024 01:17:07 GMT, Brian Burkhalter wrote:
> Align the specification of `Unsafe.allocateMemory` with its implementation
> and with the specification of `Unsafe.reallocateMemory`.
lgtm
-
Marked as reviewed by rriggs (Reviewer).
PR Review:
On Wed, 31 Jan 2024 23:53:16 GMT, Sandhya Viswanathan
wrote:
>> src/hotspot/cpu/x86/c2_MacroAssembler_x86.cpp line 1613:
>>
>>> 1611: vpand(xtmp, idx_vec, xtmp, vlen_enc);
>>> 1612: // Load double words from normalized indices.
>>> 1613: evpgatherdd(dst, gmask, Address(base, xtmp,
> Hi All,
>
> This patch optimizes sub-word gather operation for x86 targets with AVX2 and
> AVX512 features.
>
> Following is the summary of changes:-
>
> 1) Intrinsify sub-word gather using hybrid algorithm which initially
> partially unrolls scalar loop to accumulates values from gather
On Thu, 1 Feb 2024 12:13:08 GMT, Alan Bateman wrote:
> Can you confirm that you've run tier1-4 at least? Some of the library code
> that is changed here is not tested in the lower tiers.
I have run tier1-4 now, and it passes (bar the tests that are currently failing
in mainline). However,
On Thu, 1 Feb 2024 13:47:45 GMT, Matthias Baesken wrote:
>> After adding this additional patch I fully build fastdebug on AIX (hav to
>> admit it does not look very nice).
>>
>>
>> diff --git
>> a/src/java.desktop/share/native/libawt/java2d/pipe/BufferedRenderPipe.c
>>
On Thu, 1 Feb 2024 14:25:24 GMT, Per Minborg wrote:
>> src/java.base/share/classes/jdk/internal/foreign/LayoutPath.java line 454:
>>
>>> 452: }
>>> 453:
>>> 454: public static final class SequenceElement
>>
>> Why are these not empty records?
>
> I had that in the beginning but
On Thu, 1 Feb 2024 11:57:04 GMT, Magnus Ihse Bursie wrote:
> This is a follow-up on
> [JDK-8324053](https://bugs.openjdk.org/browse/JDK-8324053). I have run the
> bin/blessed-modifier-order.sh on the entire code base, and manually checked
> the result. I have reverted all but these trivial
On Thu, 1 Feb 2024 00:28:26 GMT, Paul Sandoz wrote:
>> I guess the fact that the Java objects are 8 byte alignment padded and the
>> alignment being done at lines 1609-1611 and 1616-1621 somehow takes care of
>> this.
>
> Drive by comment, that can change with Project Lilliput.
I don't think
On Wed, 31 Jan 2024 18:21:09 GMT, Maurizio Cimadamore
wrote:
>> This PR proposes to implement `hashCode()` and `equals()` methods for
>> implementations of `PathElement`.
>>
>> In doing so, the previous `PathElementImpl` was removed and replaced in
>> favor of distinct `record`
On Thu, 1 Feb 2024 13:47:45 GMT, Matthias Baesken wrote:
>> After adding this additional patch I fully build fastdebug on AIX (hav to
>> admit it does not look very nice).
>>
>>
>> diff --git
>> a/src/java.desktop/share/native/libawt/java2d/pipe/BufferedRenderPipe.c
>>
> Similar to [JDK-8318696](https://bugs.openjdk.org/browse/JDK-8318696), we
> should use -D_FILE_OFFSET_BITS=64, and not -D_LARGEFILE64_SOURCE in the JDK
> native libraries.
Magnus Ihse Bursie has updated the pull request with a new target base due to a
merge or a rebase. The pull request now
> Similar to [JDK-8318696](https://bugs.openjdk.org/browse/JDK-8318696), we
> should use -D_FILE_OFFSET_BITS=64, and not -D_LARGEFILE64_SOURCE in the JDK
> native libraries.
Magnus Ihse Bursie has updated the pull request incrementally with one
additional commit since the last revision:
On Wed, 31 Jan 2024 09:19:39 GMT, Matthias Baesken wrote:
>> Magnus Ihse Bursie 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 seven
>>
On Wed, 31 Jan 2024 10:03:23 GMT, Aggelos Biboudis
wrote:
>> This is the proposed patch for Primitive types in patterns, instanceof, and
>> switch (Preview).
>>
>> Draft spec here: https://cr.openjdk.org/~abimpoudis/instanceof/latest/
>
> Aggelos Biboudis has updated the pull request with a
On Thu, 1 Feb 2024 11:57:04 GMT, Magnus Ihse Bursie wrote:
> This is a follow-up on
> [JDK-8324053](https://bugs.openjdk.org/browse/JDK-8324053). I have run the
> bin/blessed-modifier-order.sh on the entire code base, and manually checked
> the result. I have reverted all but these trivial
`java.lang.classfile.CodeBuilder` contains more than 230 API methods.
Existing ClassFile API use cases proved the concept one big CodeBuilder is
comfortable. However there are some redundancies, glitches in the naming
conventions, some frequently used methods are hard to find and some methods
On Wed, 31 Jan 2024 14:52:58 GMT, Maurizio Cimadamore
wrote:
>> src/java.base/share/classes/java/lang/foreign/Arena.java line 261:
>>
>>> 259:
>>> 260: /**
>>> 261: * {@return a new shared arena} Segments allocated with the shared
>>> arena can be
>>
>> Suggestion:
>>
>> *
On Wed, 31 Jan 2024 14:51:34 GMT, Maurizio Cimadamore
wrote:
>> This PR fixes a typo in the documentation for the `Arena::ofShared`.
>
> src/java.base/share/classes/java/lang/foreign/Arena.java line 261:
>
>> 259:
>> 260: /**
>> 261: * {@return a new shared arena} Segments allocated
On Wed, 31 Jan 2024 00:34:40 GMT, Paul Sandoz wrote:
>> test/jdk/jdk/incubator/vector/templates/X-LoadStoreTest.java.template line
>> 271:
>>
>>> 269: @DontInline
>>> 270: static $abstractvectortype$ fromArray($type$[] a, int i) {
>>> 271: return ($abstractvectortype$)
On Wed, 31 Jan 2024 13:12:10 GMT, Per Minborg wrote:
> This PR fixes a typo in the documentation for the `Arena::ofShared`.
Ugh - I typed these comments, but forgot to click on the big review button :-(
src/java.base/share/classes/java/lang/foreign/Arena.java line 261:
> 259:
> 260: /**
On Tue, 30 Jan 2024 14:15:57 GMT, Magnus Ihse Bursie wrote:
>> Similar to [JDK-8318696](https://bugs.openjdk.org/browse/JDK-8318696), we
>> should use -D_FILE_OFFSET_BITS=64, and not -D_LARGEFILE64_SOURCE in the JDK
>> native libraries.
>
> Magnus Ihse Bursie has updated the pull request with
8325001: Typo in the javadocs for the Arena::ofShared method
-
Commit messages:
- Backport 6b84f9bb3ee4362bf9daa4fb3905b168f9035336
Changes: https://git.openjdk.org/jdk22/pull/100/files
Webrev: https://webrevs.openjdk.org/?repo=jdk22=100=00
Issue:
This is a follow-up on
[JDK-8324053](https://bugs.openjdk.org/browse/JDK-8324053). I have run the
bin/blessed-modifier-order.sh on the entire code base, and manually checked the
result. I have reverted all but these trivial and uncontroversial changes.
Almost all of these are about moving
On Wed, 31 Jan 2024 13:12:10 GMT, Per Minborg wrote:
> This PR fixes a typo in the documentation for the `Arena::ofShared`.
This pull request has now been integrated.
Changeset: 6b84f9bb
Author:Per Minborg
URL:
On Mon, 29 Jan 2024 19:45:41 GMT, Paul Sandoz wrote:
> The implementation of method `VectorSpecies::fromMemorySegment`, in
> `AbstractSpecies::fromMemorySegment`, neglects to perform bounds checks on
> the offset argument when the method is compiled by C2 (bounds checks are
> performed when
On Wed, 31 Jan 2024 09:19:39 GMT, Matthias Baesken wrote:
>> Magnus Ihse Bursie 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 seven
>>
69 matches
Mail list logo
