RFR: 8184603: Create ObjectStreamField signature lazily when possible
claes.redestad at oracle.com
Fri Jul 14 13:40:05 UTC 2017
On 2017-07-14 15:33, Aleksey Shipilev wrote:
> On 07/14/2017 03:25 PM, Aleksey Shipilev wrote:
>> On 07/14/2017 02:47 PM, Claes Redestad wrote:
>>>> For extra points remove the superfluous null assignment of
>>>> `signature` and `field` ( as well as `offset` ).
>>> 'field' is final so that'd make javac cry bloody murder, but I fixed the
>>> rest and cleaned up a bit for consistency:
>> Can you also not do $signature field "volatile", for the sake on non-x86
>> platforms? I think getSignature() has a benign race then, which is safe.
> Hm, there is ObjectStreamField(String name, String signature, boolean unshared)
> constructor that passes naked signature.
> There are two issues here:
> a) getSignature() would now ignore the signature passed via that constructor,
> because it will redo the signature from $type field, which is initialized to
> Object.class for references;
> b) neither volatile nor blank qualifier would help to survive the racy read of
> OSF.signature field if OSF was initialized with that private constructor.
> I guess careful inspection of that constructor uses would tame these problems.
signature is already made volatile in this patch, deliberately to ensure
for the private constructors we keep correctness:
in these private constructors, the signature field is initialized in the
constructor (we can assert that it's non-null) to a value that would not
match getClassSignature(type), but since the field is volatile it will
be observed as null by a call to getSignature() on an object created with
these constructors (unless I'm mistaken, and we *do* need an added
synchonization point here).
More information about the core-libs-dev