RFR: 8247532: Records deserialization is slow

Peter Levart peter.levart at gmail.com
Wed Jun 17 06:08:20 UTC 2020


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





More information about the core-libs-dev mailing list