Age | Commit message (Collapse) | Author |
|
AdServices module
Test: Presubmits
Change-Id: Ib61861afd2d7531aeeecc6eea46b01b33273442b
Bug: b/237838314
Merged-In: Ia0334515e78988bb13a61d7b68d6549003019fd0
|
|
Added SPDX-license-identifier-Apache-2.0 to:
Android.bp
annotation-stubs/Android.bp
auth/Android.bp
compiler/Android.bp
context/Android.bp
core/Android.bp
netty/shaded/Android.bp
okhttp/Android.bp
protobuf-lite/Android.bp
protobuf/Android.bp
stub/Android.bp
testing/Android.bp
Bug: 68860345
Bug: 151177513
Bug: 151953481
Test: m all
Exempt-From-Owner-Approval: janitorial work
Change-Id: I98975a2b1aa17d6a6b70cfa41f0b9ce6e217489b
|
|
Updates several targets within grpc-grpc-java to allow for Android and Host targets to allow the building of a gRPC client library that uess OkHttp and Protobuf Lite. This provides a lightweight client library for gRPC clients that works on both Android and Host since it uses lite protos rather than full protos.
Test: m grpc-java-okhttp-client-lite
Test: mm
Test: Manual testing using client library on Android.
Change-Id: Ib9dc14a44856914b38662c01905337f98bd8d108
|
|
Update the Java gRPC implementation source to that of a released version
(v1.16.1) instead of some intermediate commit after v1.15.0.
Test: m grpc-java
Bug: 148404241
Change-Id: I9c072aee054a4aecc1bdf39adf45e9a243b907f5
|
|
Build the library from source since the imported prebuilts are
inconsistent and incomplete. For starters, the source is that of version
1.15.0 but the imported jars are those of version 1.14.0.
More importantly the grpc-java-protobuf library depends on the
grpc-java-protobuf-lite library that is not prebuilt. This causes
runtime errors due to missing symbols that should have been caught at
compile-time.
The Soong build modules follow the upstream Bazel rules as closely as
possible. Note that some static libraries were added to the grpc-java to
maintain compatibility with other rules that depend on it since the
original prebuilt grpc-java-core jar contained all sources under core/
which is not how the library is built using Bazel.
Test: m grpc-java
Test: Diffed the entries between the old and new jars
Bug: 148404241
Change-Id: I060333a68848272d5d9e09c040c1e35451a408c6
|
|
Test: make grpc-java
Bug: None
Change-Id: I55dc3d537c87c7ffc80b23cdec48fa830e9c87db
|
|
Add basic build files for the grpc-java modules.
Still need to be added: netty, protobuf
Test: make
Bug: None
Change-Id: I9248dd23c0ec24ec0f9a15aa6f6d826b7b90d617
|
|
|
|
|
|
- Split anonymous classes in named and final classes
- Fix some Javadocs and annotate when things were added.
|
|
This PR adds an automatic gradle format checker and reformats all the *.gradle files. After this, new changes to *.gradle files will fail to build if not in good format, just like checkStyle failure.
|
|
|
|
gRPC's protobuf-lite auto-selects between full and lite protobuf based on the
value of crosstool_top. If the user is specifying their own
--android_crosstool_top, then it will not auto-detect correctly. One day,
platforms will fix problems like this, but for the moment it seems we get to
live with it.
|
|
This update automatically adds generated sources and proto IDLs to the
`idea` plugin.
|
|
Previously if protobuf-generated code triggered ErrorProne we'd have to disable
the failing check for all code in that task. With -XepExcludedPaths we can
disable the ErrorProne-checking just for protobuf. Note that we continue using
ErrorProne on our generated code. Also note this only applies to ErrorProne
checks; JDK checks still require task-level disabling.
|
|
A band aid for #3284, to make its symptoms less noticeable.
|
|
This was deprecated with Bazel 0.8.0, which now uses
@com_google_protobuf instead.
This change will break users that use
grpc_java_repositories(omit_com_google_protobuf_java=True), so I've
added a custom error message to make the resolution clearer.
|
|
|
|
|
|
|
|
|
|
|
|
InputStream by contract can return zero if requested length equal to zero.
```
If len is zero, then no bytes are read and 0 is returned;
otherwise, there is an attempt to read at least one byte.
If no byte is available because the stream is at end of file,
the value -1 is returned; otherwise, at least one byte is read
and stored into b.
```
Close #3323
|
|
This commit aligns the naming of the Bazel Maven jars with the names
used by Bazel's migration-tooling project:
https://github.com/bazelbuild/migration-tooling
Unfortunately, we can't fix @com_google_protobuf_java because it's
required by Bazel itself.
Fixes #3328
|
|
|
|
resolves #3175
|
|
|
|
This is important for stable builds, as if the signature changes the old source
may no longer validate.
|
|
Bazel third party dependencies are specified in repositories.bzl which
gives the consumer the ability to opt-out of any dependencies they use
directly in their own project.
Fixes #2756
|
|
|
|
Also, update the authors.
|
|
|
|
|
|
Initated package javadoc for
* `io.grpc.stub`,
* `io.grpc.auth`,
* `io.grpc.util`,
* `io.grpc.protobuf`,
* `io.grpc.protobuf.lite`,
* `io.grpc.protobuf.nano`
|
|
|
|
ErrorProne provides static analysis for common issues, including
misused variables GuardedBy locks.
This increases build time by 60% for parallel builds and 30% for
non-parallel, so I've provided a way to disable the check. It is on by
default though and will be run in our CI environments.
|
|
The new plugin uses a newer version of animalsniffer, allows overriding
the animalsniffer version used, and has up-to-date handling. The
up-to-date handling cuts fully incremental parallel build times in half,
from 5.5s to 2.7s.
The previous plugin was supposed to be verifying tests. However, either
it wasn't verifying them or its verification was broken.
|
|
|
|
protoc no longer builds in 3.0.0 because auto-download of the gmock zip
now fails. 3.0.2 has a fix to autogen:
https://github.com/google/protobuf/commit/bba446bbf2ac7b0b9923d4eb07d5acd0665a8cf0
All that was strictly necessary was to update .travis.yml and
buildscripts/, but it helps our sanity to keep the rest of the protobuf
versions in sync. Lite is left on its existing version, because it did
not see a bump of neither the java library nor the protoc plugin.
|
|
|
|
Before:
TransportBenchmark.unaryCall1024 true NETTY sample 4564 2188854.745 ± 71456.423 ns/op
TransportBenchmark.unaryCall1024:unaryCall1024·p0.00 true NETTY sample 1875968.000 ns/op
TransportBenchmark.unaryCall1024:unaryCall1024·p0.50 true NETTY sample 2105344.000 ns/op
TransportBenchmark.unaryCall1024:unaryCall1024·p0.90 true NETTY sample 2396160.000 ns/op
TransportBenchmark.unaryCall1024:unaryCall1024·p0.95 true NETTY sample 2535424.000 ns/op
TransportBenchmark.unaryCall1024:unaryCall1024·p0.99 true NETTY sample 3011993.600 ns/op
TransportBenchmark.unaryCall1024:unaryCall1024·p0.999 true NETTY sample 7471595.520 ns/op
TransportBenchmark.unaryCall1024:unaryCall1024·p0.9999 true NETTY sample 99090432.000 ns/op
TransportBenchmark.unaryCall1024:unaryCall1024·p1.00 true NETTY sample 99090432.000 ns/op
TransportBenchmark.unaryCall1024:·gc.alloc.rate true NETTY sample 10 2787.784 ± 169.945 MB/sec
TransportBenchmark.unaryCall1024:·gc.alloc.rate.norm true NETTY sample 10 6415272.837 ± 262.046 B/op
TransportBenchmark.unaryCall1024:·gc.churn.PS_Eden_Space true NETTY sample 10 2815.863 ± 429.465 MB/sec
TransportBenchmark.unaryCall1024:·gc.churn.PS_Eden_Space.norm true NETTY sample 10 6483440.294 ± 947355.959 B/op
TransportBenchmark.unaryCall1024:·gc.churn.PS_Survivor_Space true NETTY sample 10 2.143 ± 1.623 MB/sec
TransportBenchmark.unaryCall1024:·gc.churn.PS_Survivor_Space.norm true NETTY sample 10 4873.798 ± 3679.598 B/op
TransportBenchmark.unaryCall1024:·gc.count true NETTY sample 10 42.000 counts
TransportBenchmark.unaryCall1024:·gc.time true NETTY sample 10 155.000 ms
After:
Benchmark (direct) (transport) Mode Cnt Score Error Units
TransportBenchmark.unaryCall1024 true NETTY sample 5037 1982881.569 ± 16738.841 ns/op
TransportBenchmark.unaryCall1024:unaryCall1024·p0.00 true NETTY sample 1683456.000 ns/op
TransportBenchmark.unaryCall1024:unaryCall1024·p0.50 true NETTY sample 1918976.000 ns/op
TransportBenchmark.unaryCall1024:unaryCall1024·p0.90 true NETTY sample 2232320.000 ns/op
TransportBenchmark.unaryCall1024:unaryCall1024·p0.95 true NETTY sample 2330624.000 ns/op
TransportBenchmark.unaryCall1024:unaryCall1024·p0.99 true NETTY sample 2729574.400 ns/op
TransportBenchmark.unaryCall1024:unaryCall1024·p0.999 true NETTY sample 6127304.704 ns/op
TransportBenchmark.unaryCall1024:unaryCall1024·p0.9999 true NETTY sample 15515648.000 ns/op
TransportBenchmark.unaryCall1024:unaryCall1024·p1.00 true NETTY sample 15515648.000 ns/op
TransportBenchmark.unaryCall1024:·gc.alloc.rate true NETTY sample 10 2071.435 ± 141.669 MB/sec
TransportBenchmark.unaryCall1024:·gc.alloc.rate.norm true NETTY sample 10 4318096.849 ± 269.655 B/op
TransportBenchmark.unaryCall1024:·gc.churn.PS_Eden_Space true NETTY sample 10 2076.282 ± 323.504 MB/sec
TransportBenchmark.unaryCall1024:·gc.churn.PS_Eden_Space.norm true NETTY sample 10 4335884.918 ± 729189.378 B/op
TransportBenchmark.unaryCall1024:·gc.churn.PS_Survivor_Space true NETTY sample 10 1.567 ± 1.238 MB/sec
TransportBenchmark.unaryCall1024:·gc.churn.PS_Survivor_Space.norm true NETTY sample 10 3274.883 ± 2640.345 B/op
TransportBenchmark.unaryCall1024:·gc.count true NETTY sample 10 31.000 counts
TransportBenchmark.unaryCall1024:·gc.time true NETTY sample 10 51.000 ms
|
|
|
|
The cast required in protobuf makes me question how much I like
ReflectableMarshaller, but it seems to be pretty sound and the cast is
more an artifact of generics than the API.
Nano and Thrift were purposefully not updated, since getting just the
class requires making a new message instance. That seems a bit lame. It
probably is no burden to create an instance to get the class, and it may
not be too hard to improve the factory to provide class information, but
didn't want to bother at this point. Especially since nano users are
unlikely to need the introspection functionality.
|
|
CodedInputStream is risk averse in ways that hurt performance when
parsing large messages. gRPC knows how large the input size is as it
is being read from the wire, and only tries to parse it once the entire
message has been read in. The message is represented as chunks of
memory strung together in a CompositeReadableBuffer, and then wrapped
in a custom BufferInputStream.
When passed to Protobuf, CodedInputStream attempts to read data out
of this InputStream into CIS's internal 4K buffer. For messages that
are much larger, CIS copies from the input in chunks of 4K and saved in
an ArrayList. Once the entire message size is read in, it is re-copied
into one large byte array and passed back up. This only happens for
ByteStrings and ByteBuffers that are read out of CIS. (See
CIS.readRawBytesSlowPath for implementation).
gRPC doesn't need this overhead, since we already have the entire
message in memory, albeit in chunks. This change copies the composite
buffer into a single heap byte buffer, and passes this (via
UnsafeByteOperations) into CodedInputStream. This pays one copy to
build the heap buffer, but avoids the two copes in CIS. This also
ensures that the buffer is considered "immutable" from CIS's point of
view.
Because CIS does not have ByteString aliasing turned on, this large
buffer will not accidentally be kept in memory even if only tiny fields
from the proto are still referenced. Instead, reading ByteStrings out
of CIS will always copy. (This copy, and the problems it avoids, can
be turned off by calling CIS.enableAliasing.)
Benchmark results will come shortly, but initial testing shows
significant speedup in throughput tests. Profiling has shown that
copying memory was a large time consumer for messages of size 1MB.
|
|
Protobuf-lite since beta-4 is now more of a fork than a subset of
protobuf-java, which may cause us problems later since lite API is not
stable. Also, lite-generated code may now depend on APIs only in
protobuf-lite, so our users must depend on the protobuf-lite runtime.
Having all our users explicitly override the dependency is bothersome to
them and can easily only expose problems only after we do a release.
So now we are doing the dependency overriding; most users should "just
work" and pick up the correct protobuf artifact. I've confirmed the
exclusion is listed in the grpc-protobuf pom and "gradle dependencies"
and "mvn dependency:tree" do not include protobuf-lite for the examples.
Vanilla protobuf users are most likely to experience any breakage, which
should detect problems more quickly since we use protobuf-java more
frequently than protobuf-lite during development.
protobuf-lite does not include pre-generated code for the well-known
protos, so users will need to generate them themselves for the moment
(google/protobuf#1889).
Note that today changing deps does not noticeably reduce the method code
for our users, since ProGuard already is stripping most classes. The
difference in output is only a reduction of 3 classes and 6 methods for
the android example.
|
|
Internally toByteArray is annotated with CheckReturnValue, which can
cause a failure during compilation if the value is ignored.
|
|
|
|
|
|
Lite already worked by using the protobuf project, but would bring in
extra dependencies that are not intended to work with lite. Although
protobuf is not yet providing a lite package on Maven Central, we will
be able to swap to it once it is available.
There isn't any new original code in the Java portion, except for a new
overload in ProtoUtils that accepts Message instead of MessageLite.
Depending on Message in ProtoUtils allows us to support extra features
out-of-the-box without any changes to the generated code. For example,
JSON encoding could be supported in this way if Marshaller is enhanced.
However, now codegen must be aware of Lite in order to choose with Util
class to use. That is new code.
|