On Mon, 9 Jan 2023 09:22:25 GMT, Per Minborg wrote:
>> Currently, `java.io.Bits` is using explicit logic to read/write various
>> primitive types to/from byte arrays. Switching to the use of `VarHandle`
>> access would provide better performance and less code.
>>
>> Also, using a standard API
On Mon, 30 Jan 2023 08:41:25 GMT, Per Minborg wrote:
> > java.time.ZoneOffset
>
> Maybe I am blind but can you provide a direct reference to an exising JDK
> method in `java.time` where we can apply similar optimizations?
No problem! We can start from `java.time.ZoneOffset` and its `parse` and
On Wed, 4 Jan 2023 13:16:26 GMT, Andriy Plokhotnyuk wrote:
> java.time.ZoneOffset
Maybe I am blind but can you provide a direct reference to an exising JDK
method in `java.time` where we can apply similar optimizations?
-
PR: https://git.openjdk.org/jdk/pull/11840
On Mon, 9 Jan 2023 09:22:25 GMT, Per Minborg wrote:
>> Currently, `java.io.Bits` is using explicit logic to read/write various
>> primitive types to/from byte arrays. Switching to the use of `VarHandle`
>> access would provide better performance and less code.
>>
>> Also, using a standard API
On Tue, 17 Jan 2023 08:30:58 GMT, Sergey Tsypanov wrote:
>>> > Do you see any concrete examples of classes in the JDK that could benefit
>>> > from a "VarHandlization"?
>>>
>>> `ImageOutputStreamImpl` and `ImageInputStreamImpl` in
>>> `javax.imageio.stream` have some very similar code that mig
On Tue, 17 Jan 2023 07:43:07 GMT, Per Minborg wrote:
>>>
>>> Do you see any concrete examples of classes in the JDK that could benefit
>>> from a "VarHandlization"?
>>
>> `ImageOutputStreamImpl` and `ImageInputStreamImpl` in
>> `javax.imageio.stream` have some very similar code that might
On Tue, 17 Jan 2023 01:08:09 GMT, j3graham wrote:
> > Do you see any concrete examples of classes in the JDK that could benefit
> > from a "VarHandlization"?
>
> `ImageOutputStreamImpl` and `ImageInputStreamImpl` in `javax.imageio.stream`
> have some very similar code that might benefit. Also
On Mon, 9 Jan 2023 09:22:25 GMT, Per Minborg wrote:
>> Currently, `java.io.Bits` is using explicit logic to read/write various
>> primitive types to/from byte arrays. Switching to the use of `VarHandle`
>> access would provide better performance and less code.
>>
>> Also, using a standard API
On Wed, 4 Jan 2023 13:16:26 GMT, Andriy Plokhotnyuk wrote:
>
> Do you see any concrete examples of classes in the JDK that could benefit
> from a "VarHandlization"?
`ImageOutputStreamImpl` and `ImageInputStreamImpl` in `javax.imageio.stream`
have some very similar code that might benefit.
On Mon, 9 Jan 2023 13:17:42 GMT, Raffaello Giulietti
wrote:
>> I see - thanks for the explanation - the problem is with `floatToIntBits` vs
>> `floatToRawIntBits` in the "put" operation. The get operation is ok, but
>> then having asymmetry where we use a float VH in one case (get) but not in
On Mon, 9 Jan 2023 12:12:08 GMT, Maurizio Cimadamore
wrote:
>> For the other direction it uses the `floatToRawIntBits`:
>> https://github.com/openjdk/jdk/blob/master/src/java.base/share/classes/java/lang/invoke/X-VarHandleByteArrayView.java.template#L148-L153
>>
>> I think for symmatry we shou
On Mon, 9 Jan 2023 11:07:51 GMT, Uwe Schindler wrote:
>> src/java.base/share/classes/java/io/Bits.java line 77:
>>
>>> 75: // Using Double.longBitsToDouble collapses NaN values to a
>>> single
>>> 76: // "canonical" NaN value
>>> 77: return Double.longBitsToDouble((long)
On Mon, 9 Jan 2023 10:33:44 GMT, Maurizio Cimadamore
wrote:
>> Per Minborg has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Remove faulty test tag, improve other test tag, fix comments
>
> src/java.base/share/classes/java/io/Bits.java li
On Mon, 9 Jan 2023 09:22:25 GMT, Per Minborg wrote:
>> Currently, `java.io.Bits` is using explicit logic to read/write various
>> primitive types to/from byte arrays. Switching to the use of `VarHandle`
>> access would provide better performance and less code.
>>
>> Also, using a standard API
On Mon, 9 Jan 2023 09:22:25 GMT, Per Minborg wrote:
>> Currently, `java.io.Bits` is using explicit logic to read/write various
>> primitive types to/from byte arrays. Switching to the use of `VarHandle`
>> access would provide better performance and less code.
>>
>> Also, using a standard API
> Currently, `java.io.Bits` is using explicit logic to read/write various
> primitive types to/from byte arrays. Switching to the use of `VarHandle`
> access would provide better performance and less code.
>
> Also, using a standard API for these conversions means future `VarHandle`
> improvem
On Thu, 5 Jan 2023 12:18:58 GMT, Per Minborg wrote:
>> Currently, `java.io.Bits` is using explicit logic to read/write various
>> primitive types to/from byte arrays. Switching to the use of `VarHandle`
>> access would provide better performance and less code.
>>
>> Also, using a standard API
On Thu, 5 Jan 2023 12:18:58 GMT, Per Minborg wrote:
>> Currently, `java.io.Bits` is using explicit logic to read/write various
>> primitive types to/from byte arrays. Switching to the use of `VarHandle`
>> access would provide better performance and less code.
>>
>> Also, using a standard API
On Thu, 5 Jan 2023 12:18:58 GMT, Per Minborg wrote:
>> Currently, `java.io.Bits` is using explicit logic to read/write various
>> primitive types to/from byte arrays. Switching to the use of `VarHandle`
>> access would provide better performance and less code.
>>
>> Also, using a standard API
Hi Uwe,
you are right! It's confusing because for cases 2-4, *atomic* access is
explicitly mentioned but not for case 1. I overlooked the *atomic
access* in the sentence before and got confused.
Thanks for the clarification!
On 1/5/23 13:37, Uwe Schindler wrote:
Hi,
I answered on the PR on
On Thu, 5 Jan 2023 12:50:25 GMT, Raffaello Giulietti
wrote:
> One reason is that if the `byte[]` contains a non-canonical NaN then `get()`
> would return it. The original code first reads an integer value and then
> converts it to a floating-point value, so for backward compatibility the same
On Thu, 5 Jan 2023 12:18:58 GMT, Per Minborg wrote:
>> Currently, `java.io.Bits` is using explicit logic to read/write various
>> primitive types to/from byte arrays. Switching to the use of `VarHandle`
>> access would provide better performance and less code.
>>
>> Also, using a standard API
On Thu, 5 Jan 2023 12:18:58 GMT, Per Minborg wrote:
>> Currently, `java.io.Bits` is using explicit logic to read/write various
>> primitive types to/from byte arrays. Switching to the use of `VarHandle`
>> access would provide better performance and less code.
>>
>> Also, using a standard API
Hi,
I answered on the PR on github. The documentation is misleading:
The copypasted snippet above is misleading, you need to read the
whole statement, so an IllegalStateException can only happen for
unaligned access on access modes other than get/set (so volatile or
opaque reads): "I
On Thu, 5 Jan 2023 12:18:58 GMT, Per Minborg wrote:
>> Currently, `java.io.Bits` is using explicit logic to read/write various
>> primitive types to/from byte arrays. Switching to the use of `VarHandle`
>> access would provide better performance and less code.
>>
>> Also, using a standard API
The more I think about it, the clearer is that the first line of the
Javadoc is contrary to the other lines:
On 1/5/23 12:59, Michael Kuhlmann wrote:
* read write access modes for all T, with the exception of access modes
get and set for long and double on 32-bit platforms.
So all read write
> Currently, `java.io.Bits` is using explicit logic to read/write various
> primitive types to/from byte arrays. Switching to the use of `VarHandle`
> access would provide better performance and less code.
>
> Also, using a standard API for these conversions means future `VarHandle`
> improvem
On 1/5/23 12:40, Uwe Schindler wrote:
The copypasted snippet above is misleading, you need to read the whole statement, so an
IllegalStateException can only happen for unaligned access on access modes other than
get/set (so volatile or opaque reads): "If access is misaligned then access for
On Wed, 4 Jan 2023 14:37:34 GMT, Per Minborg wrote:
>> Currently, `java.io.Bits` is using explicit logic to read/write various
>> primitive types to/from byte arrays. Switching to the use of `VarHandle`
>> access would provide better performance and less code.
>>
>> Also, using a standard API
On Wed, 4 Jan 2023 14:37:34 GMT, Per Minborg wrote:
>> Currently, `java.io.Bits` is using explicit logic to read/write various
>> primitive types to/from byte arrays. Switching to the use of `VarHandle`
>> access would provide better performance and less code.
>>
>> Also, using a standard API
On Wed, 4 Jan 2023 14:37:34 GMT, Per Minborg wrote:
>> Currently, `java.io.Bits` is using explicit logic to read/write various
>> primitive types to/from byte arrays. Switching to the use of `VarHandle`
>> access would provide better performance and less code.
>>
>> Also, using a standard API
> Currently, `java.io.Bits` is using explicit logic to read/write various
> primitive types to/from byte arrays. Switching to the use of `VarHandle`
> access would provide better performance and less code.
>
> Also, using a standard API for these conversions means future `VarHandle`
> improvem
On Wed, 4 Jan 2023 12:40:43 GMT, Per Minborg wrote:
> > @minborg Amazing piece!
> > Will `java.lang.invoke.VarHandle` instances be shared in JDK to reuse in
> > other places?
> > The
> > [jsoniter-scala-coreJVM](https://github.com/plokhotnyuk/jsoniter-scala/tree/master/jsoniter-scala-core/jvm/s
On Wed, 4 Jan 2023 12:20:28 GMT, Per Minborg wrote:
>> Currently, `java.io.Bits` is using explicit logic to read/write various
>> primitive types to/from byte arrays. Switching to the use of `VarHandle`
>> access would provide better performance and less code.
>>
>> Also, using a standard API
On Wed, 4 Jan 2023 10:49:18 GMT, Per Minborg wrote:
>> Do we need this test at all, because this code is tested to extense through
>> RandomAccessFile? We had no test before, so why add a new one here?
>>
>> Otherwise: PR looks good.
>
>> Do we need this test at all, because this code is tested
On Wed, 4 Jan 2023 12:20:28 GMT, Per Minborg wrote:
>> Currently, `java.io.Bits` is using explicit logic to read/write various
>> primitive types to/from byte arrays. Switching to the use of `VarHandle`
>> access would provide better performance and less code.
>>
>> Also, using a standard API
> Currently, `java.io.Bits` is using explicit logic to read/write various
> primitive types to/from byte arrays. Switching to the use of `VarHandle`
> access would provide better performance and less code.
>
> Also, using a standard API for these conversions means future `VarHandle`
> improvem
On Wed, 4 Jan 2023 10:49:24 GMT, Per Minborg wrote:
>> Currently, `java.io.Bits` is using explicit logic to read/write various
>> primitive types to/from byte arrays. Switching to the use of `VarHandle`
>> access would provide better performance and less code.
>>
>> Also, using a standard API
On Wed, 4 Jan 2023 10:49:24 GMT, Per Minborg wrote:
>> Currently, `java.io.Bits` is using explicit logic to read/write various
>> primitive types to/from byte arrays. Switching to the use of `VarHandle`
>> access would provide better performance and less code.
>>
>> Also, using a standard API
On 1/4/23 09:56, Per Minborg wrote:
Currently, `java.io.Bits` is using explicit logic to read/write various
primitive types to/from byte arrays. Switching to the use of `VarHandle` access
would provide better performance and less code.
Hmh, Javadoc for MethodHandels::byteArrayViewVarHandle sa
On Wed, 4 Jan 2023 10:49:18 GMT, Per Minborg wrote:
>> Do we need this test at all, because this code is tested to extense through
>> RandomAccessFile? We had no test before, so why add a new one here?
>>
>> Otherwise: PR looks good.
>
>> Do we need this test at all, because this code is tested
> Currently, `java.io.Bits` is using explicit logic to read/write various
> primitive types to/from byte arrays. Switching to the use of `VarHandle`
> access would provide better performance and less code.
>
> Also, using a standard API for these conversions means future `VarHandle`
> improvem
On Wed, 4 Jan 2023 09:25:40 GMT, Uwe Schindler wrote:
> Do we need this test at all, because this code is tested to extense through
> RandomAccessFile? We had no test before, so why add a new one here?
>
> Otherwise: PR looks good.
There are overlaps of the RAF and Bits tests but the latter te
On Wed, 4 Jan 2023 09:01:06 GMT, Per Minborg wrote:
>> Currently, `java.io.Bits` is using explicit logic to read/write various
>> primitive types to/from byte arrays. Switching to the use of `VarHandle`
>> access would provide better performance and less code.
>>
>> Also, using a standard API
On Wed, 4 Jan 2023 09:01:06 GMT, Per Minborg wrote:
>> Currently, `java.io.Bits` is using explicit logic to read/write various
>> primitive types to/from byte arrays. Switching to the use of `VarHandle`
>> access would provide better performance and less code.
>>
>> Also, using a standard API
On Wed, 4 Jan 2023 08:57:25 GMT, Per Minborg wrote:
> Is there a better way to test packet-private methods in Bits without
> resorting to reflection?
Yes, looking for directories named java.base in the test tree and you'll see
test classes that are compiled into java.base/java.net,
java.base/
> Currently, `java.io.Bits` is using explicit logic to read/write various
> primitive types to/from byte arrays. Switching to the use of `VarHandle`
> access would provide better performance and less code.
>
> Also, using a standard API for these conversions means future `VarHandle`
> improvem
On Wed, 4 Jan 2023 08:48:56 GMT, Per Minborg wrote:
> Currently, `java.io.Bits` is using explicit logic to read/write various
> primitive types to/from byte arrays. Switching to the use of `VarHandle`
> access would provide better performance and less code.
>
> Also, using a standard API for
48 matches
Mail list logo
