RFR (S): CR 8005926: (thread) Merge ThreadLocalRandom state into java.lang.Thread (original) (raw)
Aleksey Shipilev aleksey.shipilev at oracle.com
Mon Jan 14 22:44:45 UTC 2013
- Previous message: RFR (S): CR 8005926: (thread) Merge ThreadLocalRandom state into java.lang.Thread
- Next message: RFR (S): CR 8005926: (thread) Merge ThreadLocalRandom state into java.lang.Thread
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Agreed. But I think just faking it with the plain fields is less error-prone. The memory overhead is somewhat 8x8 = 64 bytes per JVM instance.
-Aleksey.
On 01/15/2013 02:40 AM, Dr Heinz M. Kabutz wrote:
We can probably fake the serialized form with some field descriptors and a writeObject and readObject method. Then we can keep the format exactly the same as previously. The serialized form should not stop us from optimizing this very important class. Just my 2c
On 15/01/2013, Aleksey Shipilev <aleksey.shipilev at oracle.com> wrote: On 01/15/2013 02:17 AM, Alan Bateman wrote:
The other thing I notice is that the serialized form of the original ThreadLocalRandom included the padding fields, I guess they should have been transient in the original implementation.
Damn. These are the part of TLR serialized form :( http://docs.oracle.com/javase/7/docs/api/serialized-form.html#java.util.concurrent.ThreadLocalRandom Also, the class changes probably screwed up the SUID. I think we need to get the padding back (which should not be the problem since TLR is now a singleton, and add the SUID with the previous value. -Aleksey.
- Previous message: RFR (S): CR 8005926: (thread) Merge ThreadLocalRandom state into java.lang.Thread
- Next message: RFR (S): CR 8005926: (thread) Merge ThreadLocalRandom state into java.lang.Thread
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]