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

Claes Redestad claes.redestad at oracle.com
Mon Jul 17 12:16:11 UTC 2017

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

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.



More information about the core-libs-dev mailing list