Hello all;

Recently HotSpot gained additional support for transactional memory, 
<https://bugs.openjdk.java.net/browse/JDK-8031320>. This patch is a libraries 
followon to that change. RTM and other transactional memory implementations 
benefit from clustering writes towards the end of the transaction whenever 
possible. This change optimizes the behaviour of two collection classes, 
Hashtable and Vector by moving several field updates to cluster them together 
near the end of the transaction. Yes, we know, these are obsolete collections 
but these two classes were used as the basis for the original benchmarking and 
evaluation during the development of the transactional memory JVM features. 
Future changes providing similar optimizations to other collections will be 
pursued when it can be shown they offer value and don't add a cost to non TM 
performance (TM is not yet a mainstream feature).

https://bugs.openjdk.java.net/browse/JDK-8020860
http://cr.openjdk.java.net/~mduigou/JDK-8020860/0/webrev/

It is not expected that this change will have any meaningful impact upon 
performance (either positive or negative) outside of TM-enabled configurations. 
The main change is to move existing field updates towards the end of the 
transaction and avoid conditionals between field updates.

There is a slight behaviour change introduced in this changeset. Previously 
some methods updated the modcount unconditionally updated even when an 
ArrayIndexOutOfBoundsException was subsequently thrown for an invalid index and 
the Vector was not modified. With this change the modcount will only be updated 
if the Vector is actually changed. It is not expected that applications will 
have relied or should have relied on this behaviour.

Mike

Reply via email to