Tag Archives: JNI


by Mikhail Vorontsov

IdentityHashMap is the only map in JDK useful for tracking objects by identity (object is identical only to itself) instead of tracking by equality (if object1.equals( object2 ), they are equal). IdentityHashMap is used mostly in cases when you can’t modify tracked objects definition by either adding additional fields or writing equals and hashCode methods.

Let’s see how some of these limitations could be removed:

  • If you can’t add equals and hashCode to the class (or it has different implementations of these methods), it could be solved by Trove maps custom hashing strategies.
  • If there is a primary key field in the object – try to use an ordinary map with this field as a key instead of IdentityHashMap with object itself as a key.

IdentityHashMap calls System.identityHashCode to get object identity hash code – some semi-unique int value identifying each object. System.identityHashCode belongs to a set of Java intrinsic methods, which is a small set of core Java methods, which are directly (or nearly directly) mapped onto single (or just a few) CPU instructions.

You can find the list of Java 8 intrinsic methods in this listing. Look for do_intrinsic macros in the second half of the file.

Continue reading

java.util.zip.CRC32 and java.util.zip.Adler32 performance

by Mikhail Vorontsov

Checksum is a function from an arbitrary size input byte array to a small number of bytes (integer in case of CRC32 and Adler32). Its most important property is that a small change in the input data (even one byte is increased by one) means a large change in the checksum. Checksums are usually calculated in one of two following scenarios:

  • A file was received with a separately received checksum. We need to calculate a checksum on the file contents and compare it with the received checksum to ensure that the file was not changed during transmission.
  • A file is being read from an input device and a checksum is being calculated on its contents. Partial file contents are being somehow processed. In some occasions connection with the input device may be broken and retransmission is required. We may use the last calculated checksum and its file position in order to check that the same data is being received during retransmission until the last known file position in order not to reprocess the retransmitted file and continue processing after that position.

The most well-known checksum implementation from standard JDK is java.util.zip.CRC32. A lot of developers think that it is the only standard checksum implementation (a lot of them would tell ‘standard CRC implementation’). Actually, there is one more checksum implementation called java.util.zip.Adler32. Both CRC32 and Adler32 implement the same interface – java.util.zip.Checksum.

Continue reading