Use lower-entropy random UUIDs #2358
Assignees
Comments
alecgrieser
added a commit
to alecgrieser/fdb-record-layer
that referenced
this issue
Nov 14, 2023
To avoid synchronization, calls to the high-entropy `java.util.UUID.randomUUID` method are replaced here with calls to a new method that takes a configurable source randomness (defaulting to a thread-local random). This should be more performant, due to the removal of some synchronization points. In most cases, we don't have a need for cryptographically secure UUIDs. For instance, this is used by the planner to assign IDs, but all of the planner objects are created within the same thread, so the thread-local random should be sufficient. The R-tree also uses UUIDs for that purpose, but there, the uniqueness of the UUIDs is important for ensuring uniqueness of different nodes in the tree, so that usage has not been updated here. This resolves FoundationDB#2358.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
The Java function
UUID.randomUUIDuses a cryptographically secure random number generator. This can lead to performance bottlenecks for highly concurrent use cases, as there is a lock around the random number generator. However, for effectively all of our random UUIDs (with maybe one exception, in the R-tree), we don't really need secure randomness, and so the lock maintenance is wasted effort.The text was updated successfully, but these errors were encountered: