The base class already has this int, this one just confusingly shadows the base class variable and makes it so one can be memoized and the other one not (they can never be a different value and both set).
This makes DynamicMessage behavior match gencode, where the gencode uses the superclass's memoizedSize variable.
PiperOrigin-RevId: 886813561
This was for the experimental runtime, which is now defunct and we don't have any immediate plan to resurrect.
Removing this will unlock the ability to remove FieldOrder.DESCENDING in a followup change, which will result in benefits to the in-real-use paths for Android which currently have paths for both ASCENDING and DESCENDING.
PiperOrigin-RevId: 884389156
- Reuse existing local variables for field offsets in isFieldPresent.
- Avoid redundant bitwise operations in isOneofCaseEqual and setOneofPresent.
- Move numberAt(pos) inside the switch cases where it is actually used in isInitialized.
PiperOrigin-RevId: 878665459
This fixes https://github.com/protocolbuffers/protobuf/issues/26058
Mechanically, this adds tracking to MessageSchema in the intArray to include bufferIndex offsets of one member of each oneof in a message. Then in the equals function, when iterating all fields, we skip the oneof fields and do a supplemental pass over the intArray to cover the representative members of the oneofs.
In the course of adding this, I noticed we no longer needed the intArray to track repeated fields so I removed that. This means that this change is likely a net improvement in memory usage for MessageSchemas too as the number of oneofs in the universe of proto is likely much smaller than the number of repeated fields.
PiperOrigin-RevId: 877446720
This fixes as issue where extension names were incorrectly printed using their short name which prevents parsing and can lead to ambiguous or duplicate json keys.
This feature is gated by a boolean options printingFullyQualifiedExtensionNames and printingShortExtensionNames for testing. These methods are held back from the public API for now.
PiperOrigin-RevId: 875322649
When the superclass AbstractProtobufList implemented equals, it has to
call virtual .get(i), which can't be inlined because it's not sure which
subclass to inline.
If we put equals in the subclass ProtobufArrayList, then we can use
array index access rather than .get(i), which should be faster.
I think it's possible that rearranging the order of the if-statements in the equals might yield faster results (e.g. maybe we should check if the `other` is `ProtobufArrayList` up front rather than first checking instanceof List and instanceof RandomAccess, which has to loop walking the array of implemented interfaces), but this is a reasonable start; at least as fast as the existing implementation.
PiperOrigin-RevId: 874813296
schemaFor is a very hot method, called for every message we process. We only fall through to creating the schema the first time for each class, thereafter, the hot path is just getting from the ConcurrentHashMap.
Avoid R8 inlining the slow (less common) path of schemaFor. The inlining blows up the stack frame size and slows down the hot path.
PiperOrigin-RevId: 874384247
By specifying the field as its final type
This might speed up schema construction. Schema constructions is the cold path, but it's important at app startup. This is probably not going to make a big difference to benchmarks, just an opportunistic improvement.
PiperOrigin-RevId: 873770482
This change adds base tests case for printing proto2 extensions. It highlights a known issue with parsing extensions as short names and duplicated field names.
PiperOrigin-RevId: 873022900
This is a functional no-op but has fringe benefits.
Having having the constant in the Internal class makes it a static init property which has some small but undesirable implications. The specific prompt of making this change is that it was discovered that when appreduce is inline-eliminating an Internal.checkNotNull it still needs to emit the bytecode ensure that this static init is run, as the static init is an observable side effect of calling that method. The only actual side effect that this could have is if these threw an exception, which would actually be _extremely bad_ if it ever actually happened in reality, but never will throw with these particular string literals that we use, so slightly bloating bytecode just to maintain a "would break everything if its not a no-op" feels bad.
StandardCharsets was added in Java 7, and so this was not available to use when this design was initially set up.
PiperOrigin-RevId: 872430237
StreamDecoder now uses a minimum buffer size of 8 to ensure all fixed-width reads can be handled using the buffer. New tests are added to verify this behavior.
While here, create a test-only variant of ByteArrayInputStream that retains the same semantics as InputStream.read(byte[],int,int) for better test fidelity.
PiperOrigin-RevId: 868144899
This close to an effective no-op today, but in future changes we should be able to be more efficient when we are validating an entire byte[] instead of only a subrange of one.
PiperOrigin-RevId: 866457946
