Improving ThreadLocalRandom (and related classes) (original) (raw)
Aleksey Shipilev aleksey.shipilev at oracle.com
Wed Jan 9 11:25:39 UTC 2013
- Previous message: Improving ThreadLocalRandom (and related classes)
- Next message: hg: jdk8/tl/langtools: 8005167: execution time of combo tests in javac should be improved
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
On 01/09/2013 03:13 PM, Chris Hegarty wrote:
On 09/01/2013 11:10, Aleksey Shipilev wrote:
On 01/08/2013 08:07 PM, Chris Hegarty wrote:
I have no objection as such to adding certain fields to j.l.Thread to support faster ThreadLocalRandom. Maybe it would help to see how they are to be used?
I have no objections for this as well. Submitted "CR 8005926: Merge ThreadLocalRandom state into java.lang.Thread" I think the complete set of changes, including the changes to ThreadLocalRandom, should be pushed at the same time.
Yes, TLR changes are relatively hard to coordinate. I think the scope for that CR is the coordinated change in both j.u.c.TLR and j.l.Thread, maybe the CR synopsis is misleading?
I think quite some prototyping work would be needed to pull this, including intricate performance work, since this touches hardcore use cases. Also, we might need to wait for @Contended (any time now) to account for the troubles listed in another note in this thread.
-Aleksey.
- Previous message: Improving ThreadLocalRandom (and related classes)
- Next message: hg: jdk8/tl/langtools: 8005167: execution time of combo tests in javac should be improved
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]