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



Reply via email to