-
Notifications
You must be signed in to change notification settings - Fork 3.9k
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
api, core: support zero copy into protobuf #8102
Conversation
… used for okhttp as well.
…on for protobuf parse.
…y_into_protobuf_2
1c95862
to
4d90800
Compare
core/src/main/java/io/grpc/internal/CompositeReadableBuffer.java
Outdated
Show resolved
Hide resolved
…s like being exhausted after being detached.
@ejona86 Updated. PTAL and let me know if anything I am misunderstanding. Thanks you! |
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.
The comments for Detachable are probably best discussed during API review and see what people think. I think this looks pretty good. Main thing is I'd hope is we don't need all the if (detached)
checks in the implementation.
… after being detached. Further operations on the detached BufferInputStream just delegate to the empty buffer.
Updated descriptions in this PR and ExperimentalApi links in the code. Please let me know if any doc needs improvement. Thanks for the review! |
import java.io.InputStream; | ||
|
||
/** | ||
* A <i>Detachable</i> encapsulates some readable data source that can be detached and transferred |
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.
I think we need to "throw the user a bone" here and give them a better hint why this exists. Let's say something about how the detached instance can outlive the original instance. And how it may be useful in a Marshaller to perform delayed deserialization or when combined with HasByteBuffer.
An really, let's rephrase the documentation to describe this as "An extension of InputStream." I think it will make it much more clear what is going on.
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.
Updated.
Thank you for the PR! My early benchmark shows that this can save ~20% of cpu time when used in the GCS benchmark client. (link) |
A variant of #7330, taking the alternative codepath in protobuf.
Major changes of this PR:
HasByteBuffer
API that allows the marshaller to access the backing ByteBuffers directly (cherry-picked from protobuf, api, core, netty: zero copy into protobuf #7330).Detachable
API that allows the application to take over the ownership of underlying buffers and close them later.The new approach is to let the application implement a marshaller that passes ByteBuffers as immutable to protobuf:
This requires buffers to be alive all the time through the proto messages used by the application (compared to the normal codepath that makes a copy of the bytes when parsed to proto messages and recycle buffers right after). The application is responsible for managing the lifetime of underlying buffers. An example marshaller that enables zero-copy codepath can be something like the following: