RFR: 8143926: ObjectStreamField constructor eagerly load ObjectStreamClass

[Chris Hegarty]

On 29/11/15 16:42, Claes Redestad wrote:
> 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?

I see that BytecodeDescriptor has methods that offer similar
functionality, but if the primary motivation is to reduce the
number of classes loaded when ObjectStreamField is loaded, then
maybe the simplest thing to do is to move getClassSignature
to ObjectStreamField?

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

Ah, of course. It is used directly in many places.

-Chris