[10?] RFR: 8193128: Reduce number of implementation classes returned by List/Set/Map.of()

[Remi Forax]

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" <john.r.rose at oracle.com>
> À: "Paul Sandoz" <paul.sandoz at oracle.com>
> Cc: "core-libs-dev" <core-libs-dev at openjdk.java.net>
> 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 <paul.sandoz at oracle.com> 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.