RFR (S): CR 8005926: (thread) Merge ThreadLocalRandom state into java.lang.Thread (original) (raw)
Chris Hegarty chris.hegarty at oracle.com
Mon Jan 14 22:58:31 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 ]
On 14 Jan 2013, at 22:53, Aleksey Shipilev <aleksey.shipilev at oracle.com> wrote:
On 01/15/2013 02:47 AM, Chris Hegarty wrote:
On 14 Jan 2013, at 22:33, 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. Or serialPersistentFields? I was thinking of this anyway, so we could get rid of rnd. I'm not sure what we are saving here. Since new TLR is a singleton, we save ~64 bytes per classloader. Worth messing with advanced serialization mechanics? Probably not. I'll publish a revised webrev soon.
serialPersistentFields is really quite simple, and will help avoid any potential issues like this in the future. I can help implement this on top of your patch if you like.
-Chris.
-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 ]