[10] RFR: 8184603: Create ObjectStreamField signature lazily when possible

[Claes Redestad]

Hi Peter!

On 2017-07-15 14:08, Peter Levart wrote:
>
> It seems that interning signature(s) is important for correctness (for 
> example, in ObjectOutputStream.writeTypeString(str) the 'str' is used 
> to lookup a handle so that handles are put into stream instead of the 
> type signature(s) for multiple references to the same type). Looking 
> up objects in handles table is based on identity comparison.

Yes, interned signatures is important for correctness (and performance?)
of the current serialization implementation.

>
> But there might be a way to obtain a singleton signature String per 
> type and still profit. By adding a field to java.lang.Class and 
> caching the JVM signature there. This would also be a useful public 
> method, don't you think?

I have a nagging feeling that we should be careful about leaking
implementation details about the underlying VM through public APIs,
since making changes to various specifications is hard enough as it is.

>
> Out of 191 ObjectStreamField constructions I found in JDK sources, 
> there are only 39 distinct field types involved, so the number if 
> intern() calls is reduced by a factor of ~5. There's no need to cache 
> signature in ObjectStreamField(s) this way any more, but there must 
> still be a single final field for ObjectStreamField(s) constructed 
> with explicit signature(s).
>
> Here's how this looks like in code:
>
> http://cr.openjdk.java.net/~plevart/misc/Class.getJvmTypeSignature/webrev.01/

Could this be done as a ClassValue instead of another field on Class? My
guess is only a small number of classes in any given app will be directly
involved in serialization, so growing Class seems to be a pessimization.

>
> What do you think?

I wonder what workloads actually see a bottleneck in these String.intern
calls, and *which* String.intern calls we are bottlenecking on in these
workloads. There's still a couple of constructors here that won't see a
speedup.

I think we need more data to ensure this is actually worthwhile to pursue,
or whether there are other optimizations on a higher level that could
be done.

Thanks!

/Claes