RFR: 8143926: ObjectStreamField constructor eagerly load ObjectStreamClass

Claes Redestad claes.redestad at oracle.com
Sun Nov 29 16:42:47 UTC 2015

On 2015-11-29 17:18, Alan Bateman wrote:
> On 29/11/2015 14:30, Claes Redestad wrote:
>> On 2015-11-25 16:23, Aleksey Shipilev wrote:
>>> On 11/25/2015 06:14 PM, Claes Redestad wrote:
>>>> Inlining the isPrimitive check should be enough to avoid extra 
>>>> comparisons:
>>>> http://cr.openjdk.java.net/~redestad/8143926/webrev.02
>>> Yes. Looks good!
>>> -Aleksey
>> Thanks, Aleksey!
>> Any java.io reviewers around?
> I'm not sure that it's a good idea to have the serialization code 
> making direct use of utility methods in sun.invoke.util, I wonder if 
> BytecodeDescriptor should be moved. 

I'm OK with moving these utility methods to a more neutral place, but 
since the BytecodeDescriptor utilities are public for now, maybe this 
should be a follow-up once/if
these classes become properly encapsulated?

> Also, do you have a summary as to how the ObjectStream* classes are 
> being loaded, I'm just wondering if there is an issue somewhere with 
> these being eagerly loaded.

ObjectStreamFields are created statically by a number of classes during 
startup, e.g., java.util.ConcurrentHashMap:

     /** For serialization compatibility. */
     private static final ObjectStreamField[] serialPersistentFields = {
         new ObjectStreamField("segments", Segment[].class),
         new ObjectStreamField("segmentMask", Integer.TYPE),
         new ObjectStreamField("segmentShift", Integer.TYPE),


More information about the core-libs-dev mailing list