On 03/13/2014 05:02 PM, Paul Sandoz wrote:
> On Mar 13, 2014, at 5:26 PM, Andrew Haley wrote:
>>
> A quick solution is to leverage Unsafe within a
> ByteBuffer.compareUnsigned method. In fact i believe Unsafe could be
> used (as Aleksey says in [1]) for put/get as well, which i presume
On Mar 13, 2014, at 5:26 PM, Andrew Haley wrote:
>
A quick solution is to leverage Unsafe within a
ByteBuffer.compareUnsigned method. In fact i believe Unsafe could be
used (as Aleksey says in [1]) for put/get as well, which i presume
is likely to be much easier/quicker to imp
On 03/13/2014 02:26 PM, David M. Lloyd wrote:
> On 03/13/2014 07:19 AM, Andrew Haley wrote:
>> On 03/13/2014 11:57 AM, Paul Sandoz wrote:
>>> Now i am in two minds to whether to add ByteBuffer.compareUnsigned or add
>>> Arrays.compareUnsigned.
>>>
>>> An explosion of methods on Arrays for all type
On 03/13/2014 02:19 PM, Paul Sandoz wrote:
>
> On Mar 13, 2014, at 1:57 PM, Andrew Haley wrote:
>
>> On 03/13/2014 12:49 PM, Paul Sandoz wrote:
>>> On Mar 13, 2014, at 1:19 PM, Andrew Haley wrote:
On 03/13/2014 11:57 AM, Paul Sandoz wrote:
> Now i am in two minds to whether to add Byte
On Mar 13, 2014, at 1:57 PM, Andrew Haley wrote:
> On 03/13/2014 12:49 PM, Paul Sandoz wrote:
>> On Mar 13, 2014, at 1:19 PM, Andrew Haley wrote:
>>> On 03/13/2014 11:57 AM, Paul Sandoz wrote:
Now i am in two minds to whether to add ByteBuffer.compareUnsigned or add
Arrays.compareUns
On 03/13/2014 07:19 AM, Andrew Haley wrote:
On 03/13/2014 11:57 AM, Paul Sandoz wrote:
Now i am in two minds to whether to add ByteBuffer.compareUnsigned or add
Arrays.compareUnsigned.
An explosion of methods on Arrays for all types (plus to/from versions) would
be annoying.
Surely it's a n
On 03/13/2014 12:49 PM, Paul Sandoz wrote:
> On Mar 13, 2014, at 1:19 PM, Andrew Haley wrote:
>> On 03/13/2014 11:57 AM, Paul Sandoz wrote:
>>> Now i am in two minds to whether to add ByteBuffer.compareUnsigned or add
>>> Arrays.compareUnsigned.
>>>
>>> An explosion of methods on Arrays for all t
On Mar 13, 2014, at 1:19 PM, Andrew Haley wrote:
> On 03/13/2014 11:57 AM, Paul Sandoz wrote:
>> Now i am in two minds to whether to add ByteBuffer.compareUnsigned or add
>> Arrays.compareUnsigned.
>>
>> An explosion of methods on Arrays for all types (plus to/from versions)
>> would be annoyin
On 03/13/2014 11:57 AM, Paul Sandoz wrote:
> Now i am in two minds to whether to add ByteBuffer.compareUnsigned or add
> Arrays.compareUnsigned.
>
> An explosion of methods on Arrays for all types (plus to/from versions) would
> be annoying.
Surely it's a no brainer? All we have to do is add t
On Feb 28, 2014, at 11:29 PM, Martin Buchholz wrote:
> Are word-size reads in ByteBuffer actually intrinsified? I could find no
> evidence for that. Perhaps this is an important missing optimization for
> hotspot to make?
>
> I see DirectByteBuffer, but not garden-variety ByteBuffer, using
Am 28.02.2014 23:29, schrieb Martin Buchholz:
Are word-size reads in ByteBuffer actually intrinsified? I could find no
evidence for that. Perhaps this is an important missing optimization for
hotspot to make?
I see DirectByteBuffer, but not garden-variety ByteBuffer, using Unsafe.
share/classe
On 02/28/2014 10:29 PM, Martin Buchholz wrote:
> Are word-size reads in ByteBuffer actually intrinsified?
No.
Andrew.
On 03/01/2014 02:29 AM, Martin Buchholz wrote:
> Are word-size reads in ByteBuffer actually intrinsified? I could find no
> evidence for that. Perhaps this is an important missing optimization for
> hotspot to make?
It is a missing optimization, and we will get to that:
https://bugs.openjdk.jav
On Feb 27, 2014, at 4:12 PM, Andrew Haley wrote:
> On 02/27/2014 03:05 PM, Paul Sandoz wrote:
>>
>> On Feb 27, 2014, at 3:52 PM, Andrew Haley wrote:
>>
>>> Hi,
>>>
>>> On 02/26/2014 03:42 PM, Paul Sandoz wrote:
>>>
A common reason why Unsafe is used is to more efficiently compare two
On 02/27/2014 03:05 PM, Paul Sandoz wrote:
>
> On Feb 27, 2014, at 3:52 PM, Andrew Haley wrote:
>
>> Hi,
>>
>> On 02/26/2014 03:42 PM, Paul Sandoz wrote:
>>
>>> A common reason why Unsafe is used is to more efficiently compare two
>>> unsigned byte arrays, viewing those byte arrays as long ar
On Feb 27, 2014, at 3:52 PM, Andrew Haley wrote:
> Hi,
>
> On 02/26/2014 03:42 PM, Paul Sandoz wrote:
>
>> A common reason why Unsafe is used is to more efficiently compare two
>> unsigned byte arrays, viewing those byte arrays as long arrays.
>
> Why not simply provide ByteBuffer.forArray(b
Hi,
On 02/26/2014 03:42 PM, Paul Sandoz wrote:
> A common reason why Unsafe is used is to more efficiently compare two
> unsigned byte arrays, viewing those byte arrays as long arrays.
Why not simply provide ByteBuffer.forArray(byte[]) ? Then we'd have all the
ByteBuffer intrinsics for put() a
On 02/27/2014 11:37 AM, Paul Sandoz wrote:
/*
* We want to compare only the first index where left[index] !=
right[index].
* This corresponds to the least significant nonzero byte in lw ^
rw, since lw
* and rw are little-endian. Long.numb
On Feb 26, 2014, at 6:21 PM, Martin Buchholz wrote:
> Every once in a while I see an attempt to introduce a "general purpose"
> unsafe array class, but efforts stall due to:
Yes, in general this is "arrays 2.0" stuff, which is tricky especially since on
and off-heap seem to have conflicting
19 matches
Mail list logo
