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..)



More information about the hotspot-runtime-dev mailing list