RFR: 8247532: Records deserialization is slow

[Chris Hegarty]

Peter,

Thank you for taking the suggestion for additional test scenarios, improving coverage, and finding-and-fixing the issues in my hurried test builder (was only meant as a rough guide/idea).

I agree with Claes, it would be good to include the microbenchmark in test/micro/..

I think this version, 0.6, is very good. There is quite a bit of code to deal with the caching and lookup, but I don’t see an existing alternative implementation in the JDK that could be reused or moulded to fit this particular use case.

I experimented a little with spinning a class to hold the transformed MH in the constant pool, and accessing through a SAM type, just to see it if had any positive effect on the benchmark numbers - it did not.

-Chris.


> On 21 Jun 2020, at 18:16, Peter Levart <peter.levart at gmail.com> wrote:
> 
> Hi,
> 
> 
> 
> When re-running the benchmark [1] with different lengths of serialized arrays of records, I found that, compared to classical classes, lookup into the cache of adapted method handles starts to show when the length of array is larger (# of instances of same record type deserialized in single stream). Each record deserialized must lookup the method handle in a ConcurrentHashMap:
> 
> 
> 
> Benchmark                                    (length)  Mode  Cnt    Score   Error  Units
> RecordSerializationBench.deserializeClasses        10  avgt   10    8.088 ± 0.013  us/op
> RecordSerializationBench.deserializeClasses       100  avgt   10   32.171 ± 0.324  us/op
> RecordSerializationBench.deserializeClasses      1000  avgt   10  279.762 ± 3.072  us/op
> RecordSerializationBench.deserializeRecords        10  avgt   10    9.011 ± 0.027  us/op
> RecordSerializationBench.deserializeRecords       100  avgt   10   33.206 ± 0.514  us/op
> RecordSerializationBench.deserializeRecords      1000  avgt   10  325.137 ± 0.969  us/op
> 
> 
> ...so keeping the correctly shaped adapted method handle in the per-serialization-session ObjectStreamClass instance [2] starts to make sense:
> 
> 
> 
> Benchmark                                    (length)  Mode  Cnt    Score   Error  Units
> RecordSerializationBench.deserializeClasses        10  avgt   10    8.681 ± 0.155  us/op
> RecordSerializationBench.deserializeClasses       100  avgt   10   32.496 ± 0.087  us/op
> RecordSerializationBench.deserializeClasses      1000  avgt   10  279.014 ± 1.189  us/op
> RecordSerializationBench.deserializeRecords        10  avgt   10    8.537 ± 0.032  us/op
> RecordSerializationBench.deserializeRecords       100  avgt   10   31.451 ± 0.083  us/op
> RecordSerializationBench.deserializeRecords      1000  avgt   10  250.854 ± 2.772  us/op
> 
> 
> With that, more objects means advantage over classical classes instead of disadvantage.
> 
> 
> 
> [1] http://cr.openjdk.java.net/~plevart/jdk-dev/RecordsDeserialization/RecordSerializationBench.java <http://cr.openjdk.java.net/~plevart/jdk-dev/RecordsDeserialization/RecordSerializationBench.java>
> [2] http://cr.openjdk.java.net/~plevart/jdk-dev/RecordsDeserialization/webrev.06/ <http://cr.openjdk.java.net/~plevart/jdk-dev/RecordsDeserialization/webrev.06/>
> 
> Regards, Peter
> 
> 
>