On 03/25/2014 09:37 PM, Mike Duigou wrote:
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
Hi Mike,
I don't like the principle behind this patch.
Your changing the behavior because it's better with the current state of
the implementation of the RTM.
First, as Martin said, you need a very good reason to do that and it's a
kind of black magic change, when the RTM code will change you will have
to update the JDK code too.
It's better that the VM cluster the write itself by pushing the writes
at the end of every code path if RTM is enabled
(I don't say that this is easy to implement that but it will benefit to
more code).
regards,
Rémi
