Classes, specializations, and statics

[Remi Forax]

I wonder if it's not better to have a class like ThreadLocal or ClassValue that represents a constant that can be different depending on the specialization.

Rémi

----- Mail original -----
> De: "Brian Goetz" <brian.goetz at oracle.com>
> À: "Bjorn B Vardal" <bjornvar at ca.ibm.com>
> Cc: valhalla-spec-experts at openjdk.java.net
> Envoyé: Mardi 23 Février 2016 01:23:16
> Objet: Re: Classes, specializations, and statics
> 
> It's possible that there could be multiple "ssinit" methods, each
> restricted to specific parameterizations (just like any other restricted
> method), but in general, the "ssinit" method can be specialized just
> like any other method.  So what I envision (in the absence of
> initialization of conditional members) is possibly two such methods; one
> that is specializable (corresponding to _SS members) and one that is
> not, restricted to the erased parameterization (corresponding to
> traditional statics.)
> 
> 
> 
> On 2/22/2016 4:11 PM, Bjorn B Vardal wrote:
> > I think we're on the same page regarding specialized <clinit>.
> >  - The JVM will be handed multiple <clinit> partial methods, and the
> > specializer will take care of selecting the appropriate <clinit> for
> > each specialization.
> >  - The erased <clinit> will contain the non-specialized static
> > initialization code, which ensures that it only runs once.
> >  - The erased <clinit> will always run before the first specialization
> > <clinit>.
> >  - The Java syntax is still up for discussion.
> > > I think this is mostly a matter of coming up with the right syntax,
> > which makes it clear that statics can be per-class or
> > per-specialization.  There are a whole pile of related
> > specialization-related syntax issues, I'll try to get them all in one
> > place.
> > I don't think the problem will be to make it clear that statics can be
> > per-class or per-specialization, but rather why some parameterizations
> > (which to the user are synonymous with specializations) don't appear
> > to have specialized statics. Do we want to put erasure in the face of
> > users like this? It seems better to let the users deal purely with
> > parameterizations, and we let specialization and erasure be
> > implementation details.
> > --
> > Bjørn Vårdal
> >
> >     ----- Original message -----
> >     From: Brian Goetz <brian.goetz at oracle.com>
> >     To: Bjorn B Vardal/Ottawa/IBM at IBMCA,
> >     valhalla-spec-experts at openjdk.java.net
> >     Cc:
> >     Subject: Re: Classes, specializations, and statics
> >     Date: Thu, Feb 18, 2016 7:55 PM
> >
> >
> >>     Based on the example above, I think we need to be more explicit
> >>     about how the <clinit> method is handled.
> >>     There are really two different sets of statics that need to be
> >>     handled by the class initialization:
> >>     A) common statics (shared across all instantiations)
> >>     B) specialized statics
> >>     In addition to the statics, there is also common (and maybe
> >>     specialized?) code that is run as part of <clinit>.
> >
> >     There is a reasonable model to collapse these back into one
> >     concept; treat "common statics" as specialized statics on the
> >     all-erased parameterization, with a <where> clause that restricts
> >     them to that parameterization.  Not clear whether we actually want
> >     to represent it that way or not, but its a useful mental model
> >     that doesn't require the creation of a third thing.  (Since
> >     Class[Foo] and ParamType[Foo,erased*] describe the same class,
> >     this is also fully binary compatible with existing classes.)
> >
> >     Which means we can do a similar thing with <clinit>, if we want.
> >     I'll wave my hands because we've not yet talked much about
> >     conditional members, but it basically looks like this:
> >
> >     <where T*=erased*>
> >     <init>() { /* common static init code */
> >                    /* specializable init code */ }
> >
> >     <init>() { /* specializable init code */ }
> >
> >     Or not.
> >>     Where will the initialization code for both kinds of statics be?
> >>      The existing <clinit> method?
> >
> >     We have two choices:
> >      - have a new <sclinit> block that gets run once per
> >     specialization, and keep <clinit>
> >      - merge the two as above, exploiting planned support for
> >     conditional members
> >
> >     Either way, as you say, we have to ensure that the common init
> >     runs exactly once.
> >>     When using *static, are we only discussing {get,put}?  Or is this
> >>     also proposing invokestatic changes to allow specialized static
> >>     methods?
> >
> >     Methods too.
> >>     All of the technical details aside, is this something we really
> >>     want to expose to the users?  They're going to have a hard time
> >>     understanding why Foo<int> (or Foo<ValueType) gets specialized
> >>     statics while Foo<String> & Foo<Bar> share the erased version.
> >
> >     I think this is mostly a matter of coming up with the right
> >     syntax, which makes it clear that statics can be per-class or
> >     per-specialization.  There are a whole pile of related
> >     specialization-related syntax issues, I'll try to get them all in
> >     one place.
> >
> >
> 
>