> On Aug 10, 2018, at 6:32 AM, Claes Redestad <claes.redes...@oracle.com> 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/
> 
> 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..)
> 

I think it’s better to include a good test case in this REF, especially since 
object archiving is a new feature.

Thanks
Ioi

> Thanks!
> 
> /Claes

Reply via email to