-
Notifications
You must be signed in to change notification settings - Fork 834
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 ByteBuffer field type marshaling support to exporter. #6686
Conversation
Codecov ReportAttention: Patch coverage is
Additional details and impacted files@@ Coverage Diff @@
## main #6686 +/- ##
============================================
- Coverage 90.10% 89.91% -0.19%
Complexity 6541 6541
============================================
Files 728 728
Lines 19695 19735 +40
Branches 1935 1938 +3
============================================
- Hits 17746 17745 -1
- Misses 1349 1389 +40
- Partials 600 601 +1 ☔ View full report in Codecov by Sentry. |
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.
Let's wait to merge until we can incorporate into #6680 to ensure this works with testing.
This is currently deliberately decoupled from the profiling exporter work, though that's clearly its intended use case in the short term. Are you saying you'd like me to bundle in here the code change to profiling that uses this, rather than doing the linkup as a separate change later? |
Yes, let's wire this into the profile marshaler where we see it being used, since that allows us to get some test coverage. (Sorry for the delay. I missed your reply.) |
65cf5a1
to
dbb782e
Compare
Use new code in profiling marshaling.
Not a problem. Done. |
The marshaling utility code has not previously needed to support encoding of ByteBuffer type fields, as they are not used by any existing protocol. With the creation of the new experimental profiling signal type, that changes.
#6680 adds support for marshaling the new signal, but converts the ByteBuffer field into byte[] first, which is not ideal. To allow the ByteBuffer to be passed directly to the serialization code, we add support through Serializer and MarshalerUtil. The bulk of the change is in CodedOutputStream, the upstream protobuf version of which has ByteBuffer support already, so this is really just reinstating it in the fork.
In so doing, I've opted to keep the data handling behaviour based on 'buffer capacity, not position/limit' semantics of the protobuf lib for consistency, though that may be seen as running contrary to the intended API usage semantics of ByteBuffer. What we expose at the user API level may or may not be the same - ProfileContainerMarshaler currently uses position/limit instead.