[JAVA-4645] Investigate ThreadLocalRandom interaction with virtual threads Created: 13/Jun/22 Updated: 07/Sep/23 Resolved: 07/Sep/23 |
|
| Status: | Closed |
| Project: | Java Driver |
| Component/s: | Internal |
| Affects Version/s: | None |
| Fix Version/s: | None |
| Type: | Improvement | Priority: | Unknown |
| Reporter: | Jeffrey Yemin | Assignee: | Unassigned |
| Resolution: | Done | Votes: | 0 |
| Labels: | loom | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Epic Link: | Virtual Threads Support |
| Quarter: | FY24Q3 |
| Backwards Compatibility: | Fully Compatible |
| Documentation Changes: | Not Needed |
| Documentation Changes Summary: | 1. What would you like to communicate to the user about this feature? |
| Description |
|
The driver uses ThreadLocalRandom in a couple of places. It's not clear how ThreadLocalRandom will work in a world with millions of virtual threads. It appears that in Java 19 ThreadLocalRandom#localInit will be called on every invocation of ThreadLocalRandom#current, which seems undesirable. |
| Comments |
| Comment by Jeffrey Yemin [ 20/Mar/23 ] |
|
I looked into this a bit more and it seems ThreadLocalRandom#localInit is not very expensive in time or space. It's essentially one CAS operation and a bit of constant-time arithmetic, resulting ultimately in the initialization of a couple of integers in the Thread instance. |
| Comment by Maxim Katcharov [ 22/Jun/22 ] |
|
If this is truly a significant problem, we might consider rolling our own PRNG/seeding that is weaker than ThreadLocalRandom but still strong enough for our purposes. For example, we might seed Random using (thread_id xor time). |