mobile: Use direct ByteBuffer to pass data between C++ and Java#32715
Merged
abeyad merged 2 commits intoenvoyproxy:mainfrom Mar 6, 2024
Merged
mobile: Use direct ByteBuffer to pass data between C++ and Java#32715abeyad merged 2 commits intoenvoyproxy:mainfrom
abeyad merged 2 commits intoenvoyproxy:mainfrom
Conversation
db9fb33 to
f456fdf
Compare
Signed-off-by: Fredy Wijaya <fredyw@google.com>
Signed-off-by: Fredy Wijaya <fredyw@google.com>
Member
Author
|
/assign @abeyad |
Member
Author
|
/retest |
abeyad
reviewed
Mar 6, 2024
Contributor
abeyad
left a comment
There was a problem hiding this comment.
Nice, thanks @fredyw ! The PR description was super helpful too.
Question from that though, you mentioned:
Create a copy of the ByteBuffer in the callbacks for further use.
So from what I understood, if we actually use the data in a callback (which is the majority case?), then both before and after will result in 2 copies of the data. Is this correct?
Member
Author
Yes, that's correct. The only thing that this PR will save is between the |
Contributor
|
Sorry, I had missed step #4 in your "Before" description, which usually involves a copy, so before is 3 copies, and after is 2 copies. Awesome! |
abeyad
approved these changes
Mar 6, 2024
mattjo
added a commit
to mattjo/envoy
that referenced
this pull request
Mar 6, 2024
* origin: (34 commits) update CODEOWNER (envoyproxy#32457) Delete unused runtime flag. (envoyproxy#32739) mobile: Use direct ByteBuffer to pass data between C++ and Java (envoyproxy#32715) quic: support cert selection by SNI, non-PEM formats (envoyproxy#32260) mobile: Replace std::thread with Envoy::Thread::PosixThread (envoyproxy#32610) grpc: Add support for max frame length in gPRC frame decoding (envoyproxy#32511) build(deps): bump google.golang.org/protobuf from 1.32.0 to 1.33.0 (envoyproxy#32728) build(deps): bump the examples-golang-network group in /examples/golang-network/simple with 1 update (envoyproxy#32732) build(deps): bump google.golang.org/protobuf from 1.32.0 to 1.33.0 in /contrib/golang/filters/http/test/test_data/property (envoyproxy#32731) build(deps): bump otel/opentelemetry-collector from `246dfe9` to `71ac13c` in /examples/opentelemetry (envoyproxy#32730) build(deps): bump the examples-grpc-bridge group in /examples/grpc-bridge/server with 2 updates (envoyproxy#32720) build(deps): bump the contrib-golang group in /contrib/golang/router/cluster_specifier/test/test_data/simple with 1 update (envoyproxy#32721) build(deps): bump the contrib-golang group in /contrib/golang/filters/http/test/test_data/echo with 1 update (envoyproxy#32722) build(deps): bump the examples-ext-authz group in /examples/ext_authz/auth/grpc-service with 1 update (envoyproxy#32723) build(deps): bump the contrib-golang group in /contrib/golang/filters/http/test/test_data/routeconfig with 1 update (envoyproxy#32724) build(deps): bump the examples-load-reporting group in /examples/load-reporting-service with 1 update (envoyproxy#32726) build(deps): bump the contrib-golang group in /contrib/golang/filters/http/test/test_data/buffer with 1 update (envoyproxy#32727) build(deps): bump the examples-golang-http group in /examples/golang-http/simple with 1 update (envoyproxy#32729) opentelemetrytracer: Add User-Agent header to OTLP trace exporters (envoyproxy#32659) build: remove incorrect cc_library after tls code move (envoyproxy#32714) ...
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
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
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.
This PR updates the JNI code to use direct
ByteBufferto pass the data between C++ and Java. This change helps to reduce the number of copying needed, especially betweenjbyteArray(C++) andbyte[](Java). The directByteBufferis backed byenvoy_datawithout any copy.Before:
Buffer:Instanceis created by Envoy.envoy_datafromBuffer::Instanceby copying.jbyteArrayfromenvoy_databy copying.jbyteArray(C++) tobyte[](Java). This typically involves a copy, but it's implementation dependent.byte[]intoByteBuffer(no copy, memory managed by the JVM).After:
Buffer:Instanceis created by Envoy.envoy_datafromBuffer::Instanceby copying.envoy_datainto directByteBuffer(no copy).ByteBufferdirectly from C++ to Java (no copy).ByteBufferin the callbacks for further use. This is needed because the directByteBufferbacked byenvoy_datawill be destroyed upon completing the callback. Technically, we could let the user-defined callback create a copy as needed, such as if it needs the data to outlive the callback lifetime. However, doing that would put a burden on the users whether or not a copy is needed and failing to do so could result in garbage data. To make things less error-prone, all data passed into the user-defined callbacks will be a copy.Reference: https://developer.android.com/training/articles/perf-jni#faq:-how-do-i-share-raw-data-with-native-code
Risk Level: medium
Testing: unit tests
Docs Changes: n/a
Release Notes: n/a
Platform Specific Features: mobile