On Wed, 24 Apr 2024 15:45:58 GMT, Brian Burkhalter wrote:
>> Prevent blocking due to a carrier thread not being released when
>> `ByteArrayOutputStream.writeTo` is invoked from a virtual thread.
>
> Brian Burkhalter has updated the pull request with a new target base due to a
> merge or a rebas
On Wed, 24 Apr 2024 15:45:58 GMT, Brian Burkhalter wrote:
>> Prevent blocking due to a carrier thread not being released when
>> `ByteArrayOutputStream.writeTo` is invoked from a virtual thread.
>
> Brian Burkhalter has updated the pull request with a new target base due to a
> merge or a rebas
> Prevent blocking due to a carrier thread not being released when
> `ByteArrayOutputStream.writeTo` is invoked from a virtual thread.
Brian Burkhalter 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 i
On Wed, 24 Apr 2024 14:54:34 GMT, Viktor Klang wrote:
>> Currently we have
>>
>> public void writeTo(OutputStream out) throws IOException {
>> if (Thread.currentThread().isVirtual()) {
>> out.write(toByteArray());
>> } else synchronized (this) {
>> out
On Wed, 24 Apr 2024 14:52:45 GMT, Brian Burkhalter wrote:
>> Using a subclass to count the number of invocations of toByteArray seems a
>> bit strange but in general it is more robust to not rely on a method that
>> may be overridden by a subclass. So I think the suggestion is good.
>
> Current
On Wed, 24 Apr 2024 07:08:20 GMT, Alan Bateman wrote:
>> So do we think it better not to invoke `toByteArray` here?
>
> Using a subclass to count the number of invocations of toByteArray seems a
> bit strange but in general it is more robust to not rely on a method that may
> be overridden by a
On Tue, 23 Apr 2024 18:08:34 GMT, Brian Burkhalter wrote:
>> I was thinking more of a subclass that counted invocations to public methods
>> or metering which would cause subclass to double the counts when calling via
>> virtual thread.
>
> So do we think it better not to invoke `toByteArray` h
> Prevent blocking due to a carrier thread not being released when
> `ByteArrayOutputStream.writeTo` is invoked from a virtual thread.
Brian Burkhalter has updated the pull request incrementally with one additional
commit since the last revision:
8330748: Add vthread1.join() in test
On Tue, 23 Apr 2024 06:20:47 GMT, Alan Bateman wrote:
>> Brian Burkhalter has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> Correct ID in test @bug tag
>
> test/jdk/java/io/ByteArrayOutputStream/WriteToReleasesCarrier.java line 78:
>
>> 7
On Tue, 23 Apr 2024 17:35:42 GMT, Jason Mehrens wrote:
>> A good question. The buf/count fields are protected so the subclass has
>> direct access to the bytes. So while it could Arrays.copy the bytes, it
>> doesn't help with a buggy subclass that is changing bytes without
>> synchronization.
On Tue, 23 Apr 2024 16:08:13 GMT, Alan Bateman wrote:
>> src/java.base/share/classes/java/io/ByteArrayOutputStream.java line 164:
>>
>>> 162: public void writeTo(OutputStream out) throws IOException {
>>> 163: if (Thread.currentThread().isVirtual()) {
>>> 164: out.write(t
On Tue, 23 Apr 2024 11:16:01 GMT, Jason Mehrens wrote:
>> Brian Burkhalter has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> Correct ID in test @bug tag
>
> src/java.base/share/classes/java/io/ByteArrayOutputStream.java line 164:
>
>> 162
On Mon, 22 Apr 2024 19:49:44 GMT, Brian Burkhalter wrote:
>> Prevent blocking due to a carrier thread not being released when
>> `ByteArrayOutputStream.writeTo` is invoked from a virtual thread.
>
> Brian Burkhalter has updated the pull request incrementally with one
> additional commit since t
On Tue, 23 Apr 2024 07:27:02 GMT, Alan Bateman wrote:
> > Has the alternative of moving to a j.u.c.Lock (Needs Reentrant or not?)
> > been explored/benchmarked?
>
> Yes, decided not to do because it's just guarding access to a byte[] and any
> changes can influence the inlining. Plus, it would
On Tue, 23 Apr 2024 07:11:34 GMT, Viktor Klang wrote:
> Has the alternative of moving to a j.u.c.Lock (Needs Reentrant or not?) been
> explored/benchmarked?
Yes, decided not to do because it's just guarding access to a byte[] and any
changes can influence the inlining. Plus, it would need to c
On Mon, 22 Apr 2024 19:49:44 GMT, Brian Burkhalter wrote:
>> Prevent blocking due to a carrier thread not being released when
>> `ByteArrayOutputStream.writeTo` is invoked from a virtual thread.
>
> Brian Burkhalter has updated the pull request incrementally with one
> additional commit since t
On Mon, 22 Apr 2024 19:49:44 GMT, Brian Burkhalter wrote:
>> Prevent blocking due to a carrier thread not being released when
>> `ByteArrayOutputStream.writeTo` is invoked from a virtual thread.
>
> Brian Burkhalter has updated the pull request incrementally with one
> additional commit since t
On Mon, 22 Apr 2024 19:49:44 GMT, Brian Burkhalter wrote:
>> Prevent blocking due to a carrier thread not being released when
>> `ByteArrayOutputStream.writeTo` is invoked from a virtual thread.
>
> Brian Burkhalter has updated the pull request incrementally with one
> additional commit since t
> Prevent blocking due to a carrier thread not being released when
> `ByteArrayOutputStream.writeTo` is invoked from a virtual thread.
Brian Burkhalter has updated the pull request incrementally with one additional
commit since the last revision:
Correct ID in test @bug tag
-
Ch
Prevent blocking due to a carrier thread not being released when
`ByteArrayOutputStream.writeTo` is invoked from a virtual thread.
-
Commit messages:
- 8330748: ByteArrayOutputStream.writeTo(OutputStream) pins carrier
Changes: https://git.openjdk.org/jdk/pull/18901/files
Webrev:
20 matches
Mail list logo
