On 2014-10-17, at 5:22 PM, Staffan Friberg wrote:
>
> The polynomial used for multiplication is different so while, as with all
> CRCs, the algorithm is similar, but a different polynomial is used and the
> final checksum will be different.
Yes, I was misled by the comments. Wikipedia makes
Am 18.10.2014 um 00:38 schrieb Staffan Friberg:
Hi Ulf,
Since the default method only calls a single method it will most likely be
inlined.
After inlining the check will be
if (0 < 0 || b.length < 0 || 0 > b.length - b.length) {
throw new ArrayIndexOutOfBoundsException();
On 10/17/2014 08:58 PM, Staffan Friberg wrote:
Here is a new webrev with the updates from Alan's and Peter's
suggestions.
http://cr.openjdk.java.net/~sfriberg/JDK-6321472/webrev.01
Hi Staffan,
A few more comments...
217 if (Unsafe.ADDRESS_SIZE == 4) {
218
Good point, looks like I was overly concerned about the null check and
inlining of that method. I had to manually inline the slicing-by-8 loop
to guarantee good performance.
Removed the ENDIAN field and use ByteOrder.nativeOrder() directly instead.
New webrev - http://cr.openjdk.java.net/~sfri
Hi Ulf,
Since the default method only calls a single method it will most likely
be inlined.
After inlining the check will be
if (0 < 0 || b.length < 0 || 0 > b.length - b.length) {
throw new ArrayIndexOutOfBoundsException();
}
Which will be optimized away so only
Thanks Staffan,
You're absolutely right. Funny enough I was absolutely sure compressed ops
affected it.
Thanks
Stanimir
On Sat, Oct 18, 2014 at 12:00 AM, Staffan Friberg <
staffan.frib...@oracle.com> wrote:
> Hi Stanimir,
>
> Unsafe.ADDRESS_SIZE is the size of a native pointer, and is not aff
Hi David,
Not sure what you mean with a bit flip. Calculating CRC32 and then
flipping the result in some way?
The polynomial used for multiplication is different so while, as with
all CRCs, the algorithm is similar, but a different polynomial is used
and the final checksum will be different.
See also: http://cr.openjdk.java.net/~drchase/7088419/webrev.01/
This is the version that was not coded as an intrinsic, that also included
fork/join. The crazy Intel instructions are accessed from native code,
so you can get a feel for what the code looks like before it is converted
to an intri
Hi Stanimir,
Unsafe.ADDRESS_SIZE is the size of a native pointer, and is not affected
by how the JVM handles Java references on the heap.
--
import sun.misc.Unsafe;
public class AddressSize {
public static void main(String[] args) {
System.out.println("Address Size: " +
On 2014-10-17, at 2:53 PM, Staffan Friberg wrote:
> Fully agree that using Unsafe makes one sad.
>
> I'm just about to send out a new webrev with Alan's and Peter's comments,
> once I have that done I will give using the NIO-Buffer API a second try to
> see if using IntBuffer and LongBuffer i
Am 17.10.2014 um 20:58 schrieb Staffan Friberg:
Here is a new webrev with the updates from Alan's and Peter's suggestions.
http://cr.openjdk.java.net/~sfriberg/JDK-6321472/webrev.01
I would not remove:
86 public void update(byte[] b) {
87 adler = updateBytes(adler, b, 0, b.l
Also, ede
Unsafe.ADDRESS_SIZE == 4
That doesn't imply 32bit systems as with less than 32GiB (on 64bit) the
default is using compressed options and the address size is still only
4bytes.
I usually use something like this (in user space code) to detect the
architecture
private static final bool
I wouldn't even bother with ENDIAN field; ByteOrder.nativeOrder(), which
calls Bits.byteOrder(), which returns a static final field (modulo a null
check) should get JIT compiled into just a read of Bits.byteOrder. If
storing ByteOrder.nativeOrder() in a static final field actually makes a
differen
Hi,
I don't quite see the point of this line:
private transient final static ByteOrder ENDIAN
= ByteOrder.nativeOrder().equals(ByteOrder.BIG_ENDIAN)
? ByteOrder.BIG_ENDIAN : ByteOrder.LITTLE_ENDIAN;
should be just private static final ByteOrder ENDIAN =
ByteOrde
On 10/17/2014 04:05 AM, Alan Bateman wrote:
On 17/10/2014 02:42, Staffan Friberg wrote:
Hi,
This RFE adds a CRC-32C class. It implements Checksum so it will have
the same API CRC-32, but use a different polynomial when calculating
the CRC checksum.
CRC-32C implementation uses slicing-by-8 t
Fully agree that using Unsafe makes one sad.
I'm just about to send out a new webrev with Alan's and Peter's
comments, once I have that done I will give using the NIO-Buffer API a
second try to see if using IntBuffer and LongBuffer is able to achieve
similar performance.
As I noted in my rep
Actually I was under the impression I had included the list. Getting it
done w now.
Overall if you want speed you go unsafe (bit sad) as the JIT may not remove
the bound checks off the ByteBuffer. Unsafe is pretty ugly overall, though
and personally I try to avoid it giving up performance.
On 64b
Hi Staffan,
You're right. I thought ByteBuffer was more optimal in this respect.
Regards, Peter
On 10/17/2014 06:47 PM, Staffan Friberg wrote:
Hi Peter,
Thanks for reviewing.
I have switched to the Integer methods. Was looking through that API
but I was too stuck with the reflect and swap
On 10/17/2014 01:46 AM, Peter Levart wrote:
On 10/17/2014 03:42 AM, Staffan Friberg wrote:
Hi,
This RFE adds a CRC-32C class. It implements Checksum so it will have
the same API CRC-32, but use a different polynomial when calculating
the CRC checksum.
CRC-32C implementation uses slicing-by
In my experiments, ByteBuffer.wrap() with immediate use (e.g. BB.wrap
(...).getInt (...)) does not trigger escape analysis (I.e. the BB is not
eliminated). I suspect it's because wrap () is not trivial enough and
compiler doesn't "see through" the noise there.
Sent from my phone
On Oct 17, 2014 4
On 17/10/2014 02:42, Staffan Friberg wrote:
Hi,
This RFE adds a CRC-32C class. It implements Checksum so it will have
the same API CRC-32, but use a different polynomial when calculating
the CRC checksum.
CRC-32C implementation uses slicing-by-8 to achieve high performance
when calculating
On 17/10/2014 10:37, Paul Sandoz wrote:
Hi,
[Including compiler-dev, i am not on that list so please CC me if replying to
just that list]
I dropped this, then JVMLS got in the way... then J1 got in the way so i
better get to this before Devoxx gets in the way... Richard, thanks for your
Hi,
I have updated the webrev:
http://cr.openjdk.java.net/~kshefov/8059070/webrev.01/
-Konstantin
16.10.2014 17:24, Igor Ignatyev пишет:
Konstantin,
I haven't looked at code religiously, so I wouldn't say that I have
reviewed it. however I have some comments, please see them inline.
On 1
Hi,
[Including compiler-dev, i am not on that list so please CC me if replying to
just that list]
I dropped this, then JVMLS got in the way... then J1 got in the way so i
better get to this before Devoxx gets in the way... Richard, thanks for your
continued patience.
In the interim Richar
On 06/10/2014 11:41, Ivan Gerasimov wrote:
Hello everybody!
The append mode is emulated on Windows, therefore we have to keep a
flag indicating that.
With the current implementation, the FileDescriptor does not know if
the file were opened with O_APPEND, and the flag is maintained at the
up
On 10/17/2014 03:42 AM, Staffan Friberg wrote:
Hi,
This RFE adds a CRC-32C class. It implements Checksum so it will have
the same API CRC-32, but use a different polynomial when calculating
the CRC checksum.
CRC-32C implementation uses slicing-by-8 to achieve high performance
when calculat
26 matches
Mail list logo
