RFR: 8062771: Core reflection should use final fields whenever possible
Martin Buchholz
martinrb at google.com
Tue Nov 4 20:11:03 UTC 2014
Hi Aleksey,
On Tue, Nov 4, 2014 at 11:55 AM, Aleksey Shipilev
<aleksey.shipilev at oracle.com> wrote:
> On 04.11.2014 20:53, Martin Buchholz wrote:
>> On Tue, Nov 4, 2014 at 2:13 AM, Paul Sandoz <paul.sandoz at oracle.com> wrote:
>>> On Nov 3, 2014, at 11:18 PM, Martin Buchholz <martinrb at google.com> wrote:
> If you do this:
>
>> // Generic info repository; lazily initialized
>> - private transient ClassRepository genericInfo;
>> + private volatile transient ClassRepository genericInfo;
>
> ...you don't need to do this for correctness (but may do for performance
> -- avoidable volatile read for ARM/PPC):
It's just reflex to always read volatiles into locals - never hurts,
except the line-of-code count.
>> // accessor for generic info repository
>> private ClassRepository getGenericInfo() {
>> + ClassRepository genericInfo = this.genericInfo;
>> // lazily initialize repository if necessary
>> if (genericInfo == null) {
>> // create and cache generic info repository
>> genericInfo = ClassRepository.make(getGenericSignature(),
>> getFactory());
>> + this.genericInfo = genericInfo;
>> }
>> return genericInfo; //return cached repository
>> }
>>
>
> Also, I wonder if we need a singleton ClassRepository instance, or we
> can tolerate two different ClassRepository-ies returned under concurrent
> init.
Yeah, me too. But the existing code has this behavior as well. One
could fix it if needed with double-checked-locking or whatever our
fancy new volatile unsafe-less cas ends up looking like.
More information about the core-libs-dev
mailing list