Add ByteBuffer field type marshaling support to exporter. #6686
+103
−10
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.
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.