I don't know why this was volatile.
Volatile semantics are not strong enough for making this read-then-write a
transaction. You'd need a mutex or AtomicReference to achieve that.
Maybe it's so that if someone else has already made a EntrySet on another
thread, we can reuse that? But, it's probably cheaper to make a new EntrySet
probably than to do the volatile read-or-write (this is just a guess, may be wrong, I'm
not super experienced with the cost of volatiles).
The EntrySet is stateless (except for the state of its containing
SmallSortedMap) so it's fine to have more than one of them.
The commit introducing this doesn't explain why it's volatile, but the method
comment referring to "Similar to the AbstractMap implementation of {@code
keySet()}" may have some clues.
AbstractMap.keySet uses a transient keySet, not a volatile keySet.
Is it possible that this initial implementation mistook transient for volatile?
Anyway, it's unnecessary, let's rip it out and enjoy a little more performance.
PiperOrigin-RevId: 662071950
I've noted the rationale for this in the comment, and in the attached bug.
This should save about 4-8 bytes of memory (on the 64bit server JVM depending on if compressed object pointers are on) per object with extensions. And 4 bytes on Android.
PiperOrigin-RevId: 661900014
SerializeToString and SerializeToCord, for example, exercise codepaths that are
actually quite different, but a user would be reasonable to expect that strings
and cords are largely plug-and-play substitutable.
The templating around TYPED_TEST can eventually make it easy to add coverage
for other types as well, for example streams.
PiperOrigin-RevId: 661427989
Put the emission of braces and indentation into MayEmitIfNonDefaultCheck, this
allows for a slight beautification in the emitted code and reduces verbosity at
the call site.
Also this technically fixes the indent in some cases (specifically when
serializing some repeated fields) so that the opening braces are emitted "at
the right level".
(Previous implementations sometimes emit an extra space character.)
Compare:
{
// code ...
}
vs.
{
// code ...
}
PiperOrigin-RevId: 660236451
GPBUnknownFields will be going away in the next major release of the ObjC
Protobuf runtime. Code should be updated to make use of GPBUnknownFields
instead.
PiperOrigin-RevId: 659963056
We mostly use generated pom files in our release currently, so we can delete all the files that aren't used and the tools to update them.
Note, java/bom/pom.xml java/pom.xml and java/protoc/pom.xml are all still used at release and java/kotlin/pom.xml is used for documentation so all of those need to stay for now.
PiperOrigin-RevId: 659664012
The arena and the heap representation are both aligned to 8 bytes so we can use the lowest 3 bits of the heap pointer to encode whether the RepeatedField is in SOO mode or not, and if it is in SOO mode, to record the size. Therefore, we can have SOO sizes from 0 to 3 and one bit for whether we're in SOO mode. Note that we also tried using 3 bits for SOO size with a sentinel value for not-SOO-mode, but that was slower.
PiperOrigin-RevId: 659578775
Hong Shin
Mark Hansen
Dmitri Gribenko
Sandy Zhang
Tony Liao
Mike Kruskal
Protobuf Team Bot
Jakob Buchgraber
Jie Luo
Yamil Morales
Evan Brown
Protobuf Team Bot
Chris Kennelly
Thomas Van Lenten
Cong Liu
Deanna Garcia