-
Notifications
You must be signed in to change notification settings - Fork 728
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
Add JFR ThreadContextSwitchRate support #20725
base: master
Are you sure you want to change the base?
Conversation
@tajila FYI |
5a1927f
to
79fbfc8
Compare
@gengchen please rebase these changes |
@theresa-m please review these changes |
921b010
to
1f112d9
Compare
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.
Can you either document or point me toward more details for the expected behavior of ThreadContextSwitchRate?
runtime/vm/JFRConstantPoolTypes.cpp
Outdated
entry->switchRate = threadContextSwitchRateData->switchRate; | ||
|
||
index = _threadContextSwitchRateCount; | ||
_threadContextSwitchRateCount += 1; | ||
|
||
done: | ||
return index; |
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.
Why does this method return a value? The result is not used.
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.
This is just to be consistent with the initial JFR code in case we need the result 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.
This is just to be consistent with the initial JFR code in case we need the result in the future.
The old design required the return value for all events but this is no longer needed. You can remove it from this function and we can update the others in a separate PR.
PORT_ACCESS_FROM_VMC(currentThread); | ||
OMRPORT_ACCESS_FROM_J9PORT(PORTLIB); | ||
|
||
uint64_t switches; |
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.
Please declare variables as the first line after the if statement.
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 don't see a problem here?
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 in vm code variable declarations go at the top to support old compilers. I see both patterns in this file so I'm not sure if that applies to cpp @tajila ?
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.
Do you mean that the switches
should be on top of port access?
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.
Yes.
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 in vm code variable declarations go at the top to support old compilers. I see both patterns in this file so I'm not sure if that applies to cpp
This does not apply to C++ files. Due to legacy C rules (C89 and before), certain platforms will emit a warning (and error out because of warnings-as-errors
) if C code has blocks wherein there are executable statements before variable declarations. From C99 and on, this was no longer a rule, but a convention for C code.
In C++, on the other hand, it is encouraged to declare variables close to the first use; there is no restriction/danger to declaring them anywhere in the block, provided they are declared before they are used of course.
Some VM C++ code looks like C code because it once was. But we don't need to restrict ourselves to legacy C standards going forward with C++.
All that being said, this is still technically valid C since the macros PORT_ACCESS_FROM_VMC
and OMRPORT_ACCESS_FROM_J9PORT
expand to variable declarations anyways.
However, we should be initializing all variables with an explicit value, which is missing from this line.
See https://sap.github.io/SapMachine/jfrevents/21.html#threadcontextswitchrate, basically it outputs the rate of context switches in the OS. |
162aafd
to
389cd85
Compare
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.
Looks good to me except one spacing issue.
PORT_ACCESS_FROM_VMC(currentThread); | ||
OMRPORT_ACCESS_FROM_J9PORT(PORTLIB); | ||
|
||
uint64_t switches; |
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 in vm code variable declarations go at the top to support old compilers. I see both patterns in this file so I'm not sure if that applies to cpp @tajila ?
Depends on: eclipse-omr/omr#7580 Signed-off-by: Gengchen Tuo <[email protected]>
389cd85
to
99788aa
Compare
Depends on: eclipse-omr/omr#7580