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