RFR: 8247532: Records deserialization is slow

[Peter Levart]

On 6/17/20 8:08 AM, Peter Levart wrote:
>
> On 6/16/20 5:15 PM, Chris Hegarty wrote:
>> The caching is on a per-stream-field shape basis, which should be 
>> consistent in the common case, but of course is not always guaranteed 
>> to be the case, hence the need for the cache. I think that this 
>> should be fine, since the ObjectStreamClass ( that holds the cache ) 
>> is already itself cached as a weak reference. But I did wonder if the 
>> size of this new cache should be limited. Probably not worth the 
>> complexity unless it is an obvious issue.
>
> I don't think there will normally be many different shapes of the same 
> class deserialized by a single VM. Each shape means that a different 
> version of that class must have existed to serialize it. There could 
> be deliberate "forged" streams trying to inflate the cache. Are you 
> worried about that? In that case I can add logic to limit the number 
> of different shapes kept with a simple LRA (Least Recently Added) 
> strategy that would not hurt access performance.
>
>
> Regards, Peter
>
So, here's an attempt to limit the number of different shapes cached per 
class which doesn't affect the fast-path performance:


http://cr.openjdk.java.net/~plevart/jdk-dev/RecordsDeserialization/webrev.03/


Regards, Peter