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
