RFR: 8209120: Archive the Integer.IntegerCache (original) (raw)
Ioi Lam ioi.lam at oracle.com
Fri Aug 10 14:10:55 UTC 2018
- Previous message: RFR: 8209120: Archive the Integer.IntegerCache
- Next message: RFR: 8209120: Archive the Integer.IntegerCache
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
On Aug 10, 2018, at 6:32 AM, Claes Redestad <claes.redestad at 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 code an exception where @Stable is not honored yet... Typically IntegerCache:: 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
- Previous message: RFR: 8209120: Archive the Integer.IntegerCache
- Next message: RFR: 8209120: Archive the Integer.IntegerCache
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]