This repository was archived by the owner on Dec 16, 2020. It is now read-only.
-
Notifications
You must be signed in to change notification settings - Fork 85
Switch to new Stats API. #121
Merged
Merged
Changes from all commits
Commits
Show all changes
4 commits
Select commit
Hold shift + click to select a range
File filter
Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
There are no files selected for viewing
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Generally looks correct. If you know a priori some stat-names you want to use, even if it's the context of concatenating them with other stat-names, you may want to have an interface to 'remember' them into the StatNameSet to avoid taking locks here.
I think to do this you'd need to carve out more of your integer space below for names that could be explicitly declared and saved by WASM code.
The current interface you provide here where you take a string will definitely wind up taking a lock. Not sure how important that is for wasm performance.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'd rather avoid the lock or share the set in some way. In the normal case we are going to have 1 wasm VM per thread/silo and they will be registering the same stats but the stats are not known a priori (this is a dynamic plugin system).
So either std::shared_ptr over a shared StatNameSet or I reimplement it without a lock (since the VMs are always single threaded).
Alternatively I can have a separate interface for pre-registering strings for stats. That would add a good deal more complexity. We are already planning making tags first class entities. It seems like a string registration facility would fit well in that model.
However, in the short term I would like to just move to the new stat system so perhaps this code is a good interm step.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Sharing or replicating the StatNameSet is not going to help, because there will be locks on the underlying symbol table.
I'm not sure exactly what it means to have tags be first class entities, but that sounds promising :) As long as you are not converting string_view to StatName on the hot-path it should be fine.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Sorry, reflecting on my statement above, it is incorrect :)
Replicating a StatNameSet per thread will indeed eliminate global symbol-lock contention (once the system is warm, but at the cost of a lot of memory. The StatName/SymbolTable infrastructure is designed to avoid keeping elaborated stat names in memory, and StatNameSet defeats that. It was introduced for a few specific use-cases where some of the tokens used to compose stat-names are discovered only in the request, but are expected to be small in number.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
So this PR will work but it no optimal in memory use. That is fine for now since we will have to change the way WebAssembly modules are initialized in order to take advantage of per-registration of stats/symbols and we would like to avoid the global locking.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Add
TODO(jplevyak): ...to all those calls to replace it with something better in the future?There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Added a comment block.