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),
     };

/Claes



More information about the core-libs-dev mailing list