exponential backoff implementation to avoid over-polling resources#847
exponential backoff implementation to avoid over-polling resources#847shirouto wants to merge 1 commit intotypelead:masterfrom
Conversation
|
@shirouto Thank you so much for taking the time to implement this. I have spent a while thinking about this and the root problem is that we do too much polling and we shouldn't be. I went through all our uses of polling and a majority of them can be avoided and use instead Java's efficient built-in mechanisms like Object.wait() and Object.notify() for signaling. Now there are a couple of use cases that absolutely require polling (like for These changes will take time since there are a lot of moving parts and room for error, so we'll tackle these one-by-one after we have a more comprehensive test suite (the current one has very few tests that test the concurrent aspects of the runtime). In the meantime, I think we can use your exponential backoff changes. Overall, it looks ok. I just think we need to add a couple tests to make sure they don't break anything. You can add tests in Say you create a new folder in |
Description
Very naive implementation of exponential backoff to mitigate the overpolling of resources in the RTS.
How Has This Been Tested?
Very rudimentary testing, mainly to check whether the approach does improve the Warp IO issues and overusing of the CPU cores. This is an experiment and definitely a WIP.
Types of changes
Checklist: