RFR: 8209120: Archive the Integer.IntegerCache

mandy chung mandy.chung at oracle.com
Fri Aug 10 15:01:29 UTC 2018

On 8/10/18 6:32 AM, Claes Redestad wrote:
> 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/

This looks good to me.   Similar pattern may also be applied
to empty ListN, SetN, MapN added by JDK-8207263.


More information about the hotspot-runtime-dev mailing list