-
Notifications
You must be signed in to change notification settings - Fork 863
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
Context ID functionality #576
Changes from all commits
f955463
8b78baf
ca82a85
15b11b1
92cd7db
051280a
34d2327
1be3492
743959c
ef6eda2
7df3852
ac5a185
60bbb31
f8cf479
5f57bc5
bc0500f
aa42efd
074a6cc
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
Original file line number | Diff line number | Diff line change |
---|---|---|
|
@@ -1114,6 +1114,7 @@ class Recording { | |
buf->putVar32(tid); | ||
buf->putVar32(call_trace_id); | ||
buf->putVar32(event->_thread_state); | ||
buf->putVar64(Profiler::instance()->getContextId()); | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Adding an extra event attribute while overloading the JDK defined events will make the JMC parser quite unhappy. It will deal with it but for the price of doubling the memory required for the event metadata - basically, it will have to keep the JDK version as well as async-profiler version. In addition to the memory overhead there will be also CPU overhead because the parser will need to do the translation for each single event - an initial attempt to parse the event according to the JDK metadata will fail so the alternative metadata will have to be searched and used. A remedy for this would be using custom event IDs - the labels and even the names can stay the same. The only important thing is that the IDs are not clashing. I apologise for complicating the matters here but I want to avoid any nasty surprises when users are trying to consume JFRs produced by async-profiler. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more.
Nothing to apologies for, every comment that makes opensource software better is a good one. The other option would be to enable whole @apangin any thoughts on that? There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more.
I would really strongly suggest using custom event IDs (above 10000 eg. so we have a plenty of headroom for any builtin native events as well as any user defined Java events) - it would make it less of a hack. Let's face it - the events are going to have a different structure now so it is just fair that they are distinguishable from the builtin ones. And, as I already mentioned - we still can keep all the metadata so eg. the execution samples are picked by JMC to present the profiling view etc. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Looking forward to this feature will be released! Regarding this discussion, I realized that converter's JfrReader would not work if context id is introduced, because though the JFR format itself is self-describing, JfrReader hard codes the parsing logic Should we fix JfrReader as well? |
||
buf->put8(start, buf->offset() - start); | ||
} | ||
|
||
|
@@ -1126,6 +1127,7 @@ class Recording { | |
buf->putVar32(event->_class_id); | ||
buf->putVar64(event->_instance_size); | ||
buf->putVar64(event->_total_size); | ||
buf->putVar64(Profiler::instance()->getContextId()); | ||
buf->put8(start, buf->offset() - start); | ||
} | ||
|
||
|
@@ -1137,6 +1139,7 @@ class Recording { | |
buf->putVar32(call_trace_id); | ||
buf->putVar32(event->_class_id); | ||
buf->putVar64(event->_total_size); | ||
buf->putVar64(Profiler::instance()->getContextId()); | ||
buf->put8(start, buf->offset() - start); | ||
} | ||
|
||
|
@@ -1162,6 +1165,7 @@ class Recording { | |
buf->putVar32(event->_class_id); | ||
buf->put8(0); | ||
buf->putVar64(event->_address); | ||
buf->putVar64(Profiler::instance()->getContextId()); | ||
buf->put8(start, buf->offset() - start); | ||
} | ||
|
||
|
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 add javadoc here explaining that
0
value is reserved for 'no-context' and as such should not be used to refer to a valid context?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.
Done