Skip to content
Closed
Changes from 1 commit
Commits
Show all changes
31 commits
Select commit Hold shift + click to select a range
9936df1
Add mark&reset methods and canUseByteBuffer&getByteBuffer methods to …
voidzcy Aug 17, 2020
aa93e1d
Default implementations.
voidzcy Aug 17, 2020
454e224
Wire new methods for forwarder
voidzcy Aug 17, 2020
3f47d5e
Support mark&reset and retrieving content via ByteBuffer for netty.
voidzcy Aug 17, 2020
b3c9974
Implementation for composite.
voidzcy Aug 17, 2020
2ede525
Define interface for accessing readable content via ByteBuffers.
voidzcy Aug 17, 2020
3dca312
Implement mark&reset for simple readable buffers.
voidzcy Aug 17, 2020
6249353
Use HasByteBuffer interface for accesing input stream's backing ByteB…
voidzcy Aug 17, 2020
29dce67
Eliminate the length argument for retrieving the ByteBuffer.
voidzcy Aug 17, 2020
22ea6c3
Do no require netty buffer to be direct from API's perspective.
voidzcy Aug 17, 2020
53e347c
Use Deque operations to avoid unncessary moves.
voidzcy Aug 17, 2020
27801fe
Make a list of ByteBuffers up-front instead of a running iterator.
voidzcy Aug 17, 2020
eb71a68
Add getByteBufferSupported method for HasByteBuffer so that it can be…
voidzcy Aug 17, 2020
5d3c657
It's not necessary to implement getByteBuffer for ByteReadbaleBufferW…
voidzcy Aug 17, 2020
9fd8d3c
Add test coverage for mark&reset and getByteBuffer for generic ByteBu…
voidzcy Aug 17, 2020
e3afe50
Add test coverage for netty's special get NIO bytebuffer operation.
voidzcy Aug 17, 2020
e2fdd07
Skip test for operations not supported by okhttp.
voidzcy Aug 17, 2020
033270b
Add test coverage for BufferInputStream with getByteBuffer operation.
voidzcy Aug 17, 2020
0622d51
Add test using a known-length input stream with getByteBuffer operati…
voidzcy Aug 17, 2020
0e8caee
Modify test method name.
voidzcy Aug 17, 2020
ba4e91b
Add test coverage for mark&reset and getByteBuffer for CompositeReada…
voidzcy Aug 17, 2020
69618b2
Add getByteBuffer support for ByteReadableBufferWrapper.
voidzcy Aug 20, 2020
437857d
Only pull ByteBuffers when message is large.
voidzcy Aug 21, 2020
1363505
Run ByteBuffer codepath only in Java 9+.
voidzcy Aug 28, 2020
c46eb73
Slight improvement for avoiding array creation if not necessary.
voidzcy Aug 28, 2020
7b4e070
Merge branch 'master' of github.com:grpc/grpc-java into impl/zero_cop…
voidzcy Aug 28, 2020
772b3ba
Change ReadableBuffer#canUseByteBuffer to hasByteBuffer.
voidzcy Sep 1, 2020
b1c99e5
Removed unnecessary reset.
voidzcy Sep 1, 2020
692076c
Simplify checking runtime java version.
voidzcy Sep 1, 2020
10c13b8
Add ExperimentalApi annotation.
voidzcy Sep 1, 2020
f13c165
Rename ReadableBuffer#hasByteBuffer to getByteBufferSupported.
voidzcy Sep 2, 2020
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
Prev Previous commit
Next Next commit
Make a list of ByteBuffers up-front instead of a running iterator.
  • Loading branch information
voidzcy committed Aug 17, 2020
commit 27801fea9d6786d3d1722162d003f7589b37b9b3
Original file line number Diff line number Diff line change
Expand Up @@ -37,8 +37,8 @@
import java.lang.ref.Reference;
import java.lang.ref.WeakReference;
import java.nio.ByteBuffer;
import java.util.Iterator;
import java.util.NoSuchElementException;
import java.util.ArrayList;
import java.util.List;

/**
* Utility methods for using protobuf with grpc.
Expand Down Expand Up @@ -180,7 +180,15 @@ public T parse(InputStream stream) {
// TODO(chengyuanzhang): we may still want to go with the byte array approach for small
// messages.
if (stream instanceof HasByteBuffer && stream.markSupported()) {
cis = CodedInputStream.newInstance(new KnownLengthByteBufferIterable(stream, size));
List<ByteBuffer> buffers = new ArrayList<>();
stream.mark(size);
while (stream.available() != 0) {
ByteBuffer buffer = ((HasByteBuffer) stream).getByteBuffer();
stream.skip(buffer.remaining());
buffers.add(buffer);
}
stream.reset();
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't think the reset here really serves any purpose? IIUC the mark is only done to say "don't release the stuff I'm about to read" but it will all be released when the stream is closed once this method returns regardless.

If the reset stays then to be more "correct" shouldn't stream.skip(size) also be called after CodedInputStream.newInstance(buffers)?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks to #7330 (comment).

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@voidzcy I was referring to this specific line here, not the existence of the reset() method. This line could be deleted, right?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I see. Deleted.

cis = CodedInputStream.newInstance(buffers);
} else if (size > 0 && size <= DEFAULT_MAX_MESSAGE_SIZE) {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This check should still be done in the new case I think?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We have decided to keep "normal" messages (2~4 KB) in the current codepath, copying small things isn't necessarily bad with CPU caches. So we only enable this for messages >= 64 KB (most messages should be below this threshold).

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Sounds reasonable, would be interesting to benchmark different message sizes/sparsity to verify the threshold (of course likely system dependent).

But what about the size <= DEFAULT_MAX_MESSAGE_SIZE check?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

For large messages (larger than DEFAULT_MAX_MESSAGE_SIZE), we would prefer the ByteBuffer approach if it is supported. This shouldn't cause a problem.

Reference<byte[]> ref;
// buf should not be used after this method has returned.
Expand Down Expand Up @@ -263,57 +271,4 @@ public T parseBytes(byte[] serialized) {
}
}
}

private static final class KnownLengthByteBufferIterable implements Iterable<ByteBuffer> {
private final InputStream stream;
private final int length;

private KnownLengthByteBufferIterable(InputStream stream, int length) {
this.stream = stream;
this.length = length;
stream.mark(length);
}

@Override
public Iterator<ByteBuffer> iterator() {
try {
stream.reset();
stream.mark(length);
return new Iterator<ByteBuffer>() {
private ByteBuffer buffer;

@Override
public boolean hasNext() {
if (buffer != null) {
return true;
}
buffer = ((HasByteBuffer) stream).getByteBuffer();
return buffer != null;
}

@Override
public ByteBuffer next() {
if (!hasNext()) {
throw new NoSuchElementException();
}
ByteBuffer res = buffer;
try {
stream.skip(buffer.remaining());
} catch (IOException e) {
throw new RuntimeException(e);
}
buffer = null;
return res;
}

@Override
public void remove() {
throw new UnsupportedOperationException();
}
};
} catch (IOException e) {
throw new RuntimeException(e);
}
}
}
}