On Tue, 18 Feb 2025 11:01:51 GMT, Kim Barrett wrote:
>> Aleksey Shipilev has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> Revert waitForReferenceProcessing removals, see JDK-8305186
>
> There are several changes here that I think are of i
On Tue, 18 Feb 2025 10:54:13 GMT, Kim Barrett wrote:
>> Aleksey Shipilev has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> Revert waitForReferenceProcessing removals, see JDK-8305186
>
> src/java.base/share/classes/java/nio/Bits.java line
On Wed, 29 Jan 2025 19:56:00 GMT, Aleksey Shipilev wrote:
>> DirectByteBuffers are still using old `jdk.internal.ref.Cleaner`
>> implementation. That implementation carries a doubly-linked list, and so
>> makes DBB suffer from the same issue fixed for generic
>> `java.lang.ref.Cleaner` users w
On Mon, 10 Feb 2025 09:28:45 GMT, Aleksey Shipilev wrote:
>> @AlanBateman I've not done any work on JDK-8305186. There has also been
>> discussion about making
>> that function non-private or even public (though with concerns about
>> specification difficulty) for use in
>> places like this.
>
On Thu, 30 Jan 2025 16:25:30 GMT, Kim Barrett wrote:
>> @kimbarrett Do you have a change coming to allow waitForPendingReferences be
>> used by WB? I assume this will at least add a comment to the method (or
>> whatever it changes to) to make it clear that it's for testing.
>
> @AlanBateman I'v
On Thu, 30 Jan 2025 16:54:16 GMT, Alan Bateman wrote:
>> @kimbarrett Do you have a change coming to allow waitForPendingReferences be
>> used by WB? I assume this will at least add a comment to the method (or
>> whatever it changes to) to make it clear that it's for testing.
>
>> @AlanBateman I
On Thu, 30 Jan 2025 08:36:34 GMT, Alan Bateman wrote:
>> src/java.base/share/classes/java/nio/Bits.java line 146:
>>
>>> 144: }
>>> 145:
>>> 146: if (canary == null || canary.isDead()) {
>>
>> If we're keeping Reference.waitForPendingReferences, why not continue
On Thu, 30 Jan 2025 08:36:34 GMT, Alan Bateman wrote:
>> src/java.base/share/classes/java/nio/Bits.java line 146:
>>
>>> 144: }
>>> 145:
>>> 146: if (canary == null || canary.isDead()) {
>>
>> If we're keeping Reference.waitForPendingReferences, why not continue
On Wed, 29 Jan 2025 23:52:40 GMT, Kim Barrett wrote:
>> Aleksey Shipilev has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> Revert waitForReferenceProcessing removals, see JDK-8305186
>
> src/java.base/share/classes/java/nio/Bits.java line
On Wed, 29 Jan 2025 19:56:00 GMT, Aleksey Shipilev wrote:
>> DirectByteBuffers are still using old `jdk.internal.ref.Cleaner`
>> implementation. That implementation carries a doubly-linked list, and so
>> makes DBB suffer from the same issue fixed for generic
>> `java.lang.ref.Cleaner` users w
On Wed, 29 Jan 2025 19:56:00 GMT, Aleksey Shipilev wrote:
>> DirectByteBuffers are still using old `jdk.internal.ref.Cleaner`
>> implementation. That implementation carries a doubly-linked list, and so
>> makes DBB suffer from the same issue fixed for generic
>> `java.lang.ref.Cleaner` users w
On Wed, 29 Jan 2025 19:56:00 GMT, Aleksey Shipilev wrote:
>> DirectByteBuffers are still using old `jdk.internal.ref.Cleaner`
>> implementation. That implementation carries a doubly-linked list, and so
>> makes DBB suffer from the same issue fixed for generic
>> `java.lang.ref.Cleaner` users w
> DirectByteBuffers are still using old `jdk.internal.ref.Cleaner`
> implementation. That implementation carries a doubly-linked list, and so
> makes DBB suffer from the same issue fixed for generic
> `java.lang.ref.Cleaner` users with
> [JDK-8343704](https://bugs.openjdk.org/browse/JDK-8343704
13 matches
Mail list logo
