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

Remi Forax forax at univ-mlv.fr
Thu Dec 7 20:05:07 UTC 2017

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.

More information about the core-libs-dev mailing list