Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[WIP] New RandomNumberGenerator API #1757

Open
wants to merge 12 commits into
base: main
Choose a base branch
from

Conversation

pjfanning
Copy link
Contributor

@pjfanning pjfanning commented Jan 30, 2025

  • relates to Possibly replace ThreadLocalRandom #1749
  • experimental new RandomNumberGenerator API that allows us to plug in different RandomGenerators based on the config (to be done)
  • so far, I'm just plugging in the API to catch compile issues
  • later, I will add the new configs and RandomNumberGenerator.get() will react to the config
  • for performance reasons, the init of RandomNumberGenerator.get() will happen once so the config will be read just once
  • not necessarily going to be merged

@pjfanning pjfanning changed the title [WIP] Thread local random [WIP] New RandomNumberGenerator API Jan 30, 2025
@He-Pin
Copy link
Member

He-Pin commented Feb 11, 2025

Another thing is with the current implementation, the virtual thread is never pooled, which means the ThreadLocalRandom will not leak the thread locals

@pjfanning
Copy link
Contributor Author

So far, it seems that the performance is lower if you do not use the ThreadLocalRandom. The speed is still good and I don't think we are in a hotspot area where the small perf loss here will make a big diff. I don't think anyone should use this option unless they have a good reason to worry about their virtual thread usage leading to an excessive amount of object instance creation (one ThreadLocalRandom instance per virtual thread).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants