RFR: 8247532: Records deserialization is slow

[Chris Hegarty]

Peter,

> On 17 Jun 2020, at 09:23, Chris Hegarty <chris.hegarty at oracle.com> wrote:
> 
>> On 17 Jun 2020, at 06:44, Peter Levart <peter.levart at gmail.com> wrote:
>>>> ..
>>> If there is a way for a test to compile several versions of the same (record) class and then produce byte streams with it, then we could simulate various class-evolution cases (field missing, surplus field, change of field type, etc...) without crafting the bytestream by hand. WDYT?
>> 
>> I have a better idea. The test could contain several different classes with different names that would be used to generated variations of serialized stream. Such streams could then be "patched" so they would contain the common target class name and then used to (attempt to) deserialize the target class. I'll try to devise such test…
>> 
> I think that could work. I’ll mock something up too, just for comparison purposes.


Here is an initial version at a test that can be expanded to cover more of the stream-field shapes of serializable records.

I quickly backed away from generating the byte streams using OOS alone, since it enforces strict ordering of the fields in the stream, beyond that of primitives followed by non-primitives. And I want to be able to do things like, for example, record Point(int x, int y) - stream of x:1 y:2, or y:2 x:1 - which will verify the nominality aspect of the caching implementation. So I opted for a basic byte-stream-builder approach.

https://cr.openjdk.java.net/~chegar/serialFieldTest_webrev/test/jdk/java/io/Serializable/records/DifferentStreamFieldsTest.java.html

I also would like a builder of serial byte streams anyway, as it will be useful for things beyond this change. Maybe it could even be expanded upon and used as a test library, at some future point. The above implementation can probably be easily broken if pushed hard with larger graphs of objects, but it should be good enough for what we need here.

-Chris.