Hello,
I did an experiment with an alternative implementation of TLR:
http://dl.dropbox.com/u/101777488/TLR/webrev.01/index.html
This version is a modified proposed version. It has the following
differences:
- Instead of Thread.threadLocalRandomSeed field it has a
Thread.threadLocalRandom reference field, pointing to an instance of TLR.
- The ThreadLocalRandom is not a singleton, but an instance per thread
(like JDK7's).
- ThreadLocalRandom has a reference to constructing Thread, so it can
check the validity of calling thread.
I did some micro benchmarks and here are the results:
http://dl.dropbox.com/u/101777488/TLR/TLR_benchmark_results.txt
Results indicate that usage pattern: Thread.current().nextInt() is as
fast as proposed variant while the nextInt() method itself is as fast as
JDK7's, which is some 20% faster than proposed variant. So the
alternative implementation seems to be faster and it has the following
additional benefits:
- Checks the calling thread and throws when called from invalid thread.
- Could reinstate the padding fields (or @Contended long rnd) if needed
(the tests were done without padding)
It does have a memory overhead of one object per using thread. Not too
much I think.
Regards, Peter
On 01/15/2013 05:33 PM, Chris Hegarty wrote:
Updated webrev:
http://cr.openjdk.java.net/~chegar/8005926/webrev.01/webrev/
* based on Aleksey initial webrev
* applied serialPersistentFields, writeObject, readResolve
( as suggested by Heinz )
* did not apply readObject. It is unnecessary, defaultReadObject
will read all the fields off the stream
readResolve is necessary to give us "good" behavior ( as noted
previously ).
Once integrated, I will file a new bug to track the possible change of
serialized form of TLR, and this can then remove
serialPersistentFields and writeObject, if successful.
-Chris.
On 01/15/2013 01:57 PM, Alan Bateman wrote:
On 15/01/2013 13:49, Chris Hegarty wrote:
But wouldn't there be an issue with JDK7 TLR streams being
deserialized by JDK8, pad fields would be left in the Object input
steam? If so, then we're down the road of having to have a readObject,
etc... and possibly back to serialPersistentFields?
Technically deleting fields is an incompatible change as the stream will
not contain the fields. If someone is crazy enough to serialize with
jdk8 TLR and send it to a jdk7 release then the fields will have their
default value (as the values aren't in the stream). As the fields aren't
used then I don't think this should make a difference. Going the other
way shouldn't be an issue either as the pad fields will be ignored.
-Alan.
