RFR: 8209120: Archive the Integer.IntegerCache
Claes Redestad
claes.redestad at oracle.com
Fri Aug 10 13:32:35 UTC 2018
On 2018-08-09 18:28, Claes Redestad wrote:
>
>
> On 2018-08-09 17:41, Peter Levart wrote:
>>
>> There's danger when you overwrite a non-null @Stable field with
>> another value that this new value will not be seen. Or is <clinit>
>> code an exception where @Stable is not honored yet...
>
> Typically IntegerCache::<clinit> runs before JIT has even started, so
> I think we're OK even though the double-assignment is undefined. But
> it's a good question what happens in cases we're running AOTd code, so
> perhaps this pattern might be problematic in some future..
>>
>> To mitigate this possibility, you could have two fields:
>>
>> static Integer cache[];
>> static final Integer finalCache[];
>>
>> The 'cache' field is archived and de-archived. The final result is
>> set to 'cache' by overwriting and to 'finalCache'. The later is then
>> also used in Integer.valueOf().
>
> Right, this would be a cheap way to dispel any concerns here.
New webrev: http://cr.openjdk.java.net/~redestad/8209120/open.01/
I've verified all cases I can think of manually, but would like to defer
the creation of a sanity test to a follow-up RFE to allow time to think
through and discussing how to best go about that (do we need to verify
in depth, can we reuse some existing test etc..)
Thanks!
/Claes
More information about the core-libs-dev
mailing list