You have also the problem of people doing a lot of things in the constructor,
by example
class Foo {
@Stable final int x;
Foo() {
m();
x = 3;
m();
}
void m() {
for(...) {
// use x here
}
}
}
here, m() can be JITed with x equals to 0 as a constant and the code of m() be
re-use for the second call even if the value of x has changed in the middle.
in that case, either you need to maintain dependency between the JITed code and
the field 'x' or have a bit saying if an object is fully initialized or not,
this bit will be true at the end of the constructor and can be set for the
de-serialization too.
Rémi
----- Mail original -----
> De: "John Rose" <[email protected]>
> À: "Paul Sandoz" <[email protected]>
> Cc: "core-libs-dev" <[email protected]>
> Envoyé: Jeudi 7 Décembre 2017 20:50:01
> Objet: Re: [10?] RFR: 8193128: Reduce number of implementation classes
> returned by List/Set/Map.of()
>> On Dec 6, 2017, at 5:16 PM, Paul Sandoz <[email protected]> wrote:
>>
>> It can, since final fields are not treated as really final (unless in
>> java.lang.invoke package, where it’s as if all such fields are annotated with
>> @Stable). C2 will treat the field value a constant value if the collection is
>> held in a static final field.
>
> We could tweak the semantics of @Stable to omit the zero corner case for a
> final
> field. Then the annotation on a non-array field would mean “trust this final”.
>
> It would be yet another stop gap before that far-off day when we fix finals
> (and
> arrays). Such new uses of @Stable would have to be evaluated for any
> interaction with deserialization, so it’s not a simple decision.
