-
Notifications
You must be signed in to change notification settings - Fork 4.8k
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
mobile: Use direct ByteBuffer to pass data between C++ and Java #32715
Conversation
db9fb33
to
f456fdf
Compare
Signed-off-by: Fredy Wijaya <fredyw@google.com>
Signed-off-by: Fredy Wijaya <fredyw@google.com>
/assign @abeyad |
/retest |
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.
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?
Yes, that's correct. The only thing that this PR will save is between the |
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! |
* 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 PR updates the JNI code to use direct
ByteBuffer
to pass the data between C++ and Java. This change helps to reduce the number of copying needed, especially betweenjbyteArray
(C++) andbyte[]
(Java). The directByteBuffer
is backed byenvoy_data
without any copy.Before:
Buffer:Instance
is created by Envoy.envoy_data
fromBuffer::Instance
by copying.jbyteArray
fromenvoy_data
by 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:Instance
is created by Envoy.envoy_data
fromBuffer::Instance
by copying.envoy_data
into directByteBuffer
(no copy).ByteBuffer
directly from C++ to Java (no copy).ByteBuffer
in the callbacks for further use. This is needed because the directByteBuffer
backed byenvoy_data
will 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