<html>
  <head>
    <meta content="text/html; charset=utf-8" http-equiv="Content-Type">
  </head>
  <body bgcolor="#FFFFFF" text="#000000">
    <tt>I think there's two ways to think about "specialized statics" at
      the VM level; how you think about it conditions which way you're
      inclined to go.  <br>
      <br>
      Way 1: This is a new thing; we used to have placements for
      "static" and "instance", and now we have three placements: static,
      instance, and specialization.  We add a new bit (ACC_SPECIES), and
      define new bytecode behaviors for members with the SPECIES bit
      set.  <br>
      <br>
      Way 2: There's still only two placements, static and instance;
      per-specialization static is just the natural reinterpretation of
      "static" in the face of a many-to-one relationship between source
      classes and runtime classes.  What we used to think of static
      really is the weird case, which we can model as "new static, but
      restricted (using "where" restriction) to the all-erased
      specialization."<br>
      <br>
      Both ways are 100% compatible with existing generic sources and
      classfiles.  Way 2 (which seems more natural to me, and also means
      we don't have to invent a new thing at the VM level) exploits the
      requirement that Constant_Class[Foo] and Constant_ParamType[Foo,
      erased] *must* describe the same runtime entity.  <br>
      <br>
      With Way 2, we still (probably) have a new concept at the language
      level, which governs whether the so-described member is a member
      of all parameterizations, or only the all-erased one, but this
      gets compiled away.  This matches up with our treatment of
      erasure; it is the choice of the language compiler to choose
      erased generics or reified, and Java chooses to erase some parameterizations
      but not all.  <br>
      <br>
      .NET chooses Way 2 in the extreme; static members are not shared
      across specializations at all, since they have no notion of
      erasure.  Compatibility wouldn't let us go that far; existing
      statics are shared across all erased parameterizations, so they
      would need to remain so.  <br>
    </tt><br>
    <div class="moz-cite-prefix">On 3/18/2016 5:01 PM, Bjorn B Vardal
      wrote:<br>
    </div>
    <blockquote
      cite="mid:201603182102.u2IL2Hk5027593@d03av02.boulder.ibm.com"
      type="cite">
      <div class="socmaildefaultfont" dir="ltr"
        style="font-family:Arial;font-size:10.5pt">
        <div dir="ltr">
          <div dir="ltr">
            <div dir="ltr"><span
                style="font-family:arial,helvetica,sans-serif;"><span
                  style="font-size: 1em;"><tt><font size="3" face="">>
                    </font></tt><tt><font size="3" face="">I wonder if
                      it's not better to have a class like ThreadLocal
                      or ClassValue that </font></tt></span></span></div>
            <div dir="ltr"><span
                style="font-family:arial,helvetica,sans-serif;"><span
                  style="font-size: 1em;"><tt><font size="3" face="">>
                      represents a constant that can be different
                      depending on the specialization.</font></tt></span></span></div>
            <div dir="ltr"> </div>
            <div dir="ltr">That solution seems possible - we could
              implement specialization-specific statics as a static
              Map<Class<?>, Foo<?>>, where the type
              parameter is the key and "specialized static" is the
              value. However, it would be slower than compiling to
              static access.</div>
            <div dir="ltr"> </div>
            <div dir="ltr">Are there other use cases that make
              specialized statics necessary? So far we have empty
              collection, which can be implemented using the map.</div>
            <div dir="ltr"> </div>
            <div dir="ltr">State of the Specialization from Dec 2014
              mentioned layers - are specialized statics a step along
              the path to layers?  Will a SpecializedValue map for
              specialized statics look like an afterthought if we go the
              rest of the way to layers?</div>
            <div dir="ltr"> </div>
            <div dir="ltr">--<br>
              Bjørn Vårdal</div>
          </div>
        </div>
        <div dir="ltr"> </div>
        <blockquote data-history-content-modified="1"
          data-history-expanded="1" dir="ltr" style="border-left:solid
          #aaaaaa 2px; margin-left:5px; padding-left:5px; direction:ltr;
          margin-right:0px">----- Original message -----<br>
          From: Remi Forax <a class="moz-txt-link-rfc2396E" href="mailto:forax@univ-mlv.fr"><forax@univ-mlv.fr></a><br>
          To: Valhalla Expert Group Observers
          <a class="moz-txt-link-rfc2396E" href="mailto:valhalla-spec-observers@openjdk.java.net"><valhalla-spec-observers@openjdk.java.net></a><br>
          Cc: Bjorn B Vardal/Ottawa/IBM@IBMCA, Brian Goetz
          <a class="moz-txt-link-rfc2396E" href="mailto:brian.goetz@oracle.com"><brian.goetz@oracle.com></a><br>
          Subject: Re: Classes, specializations, and statics<br>
          Date: Tue, Feb 23, 2016 2:57 PM<br>
           
          <div><font size="2" face="Default Monospace,Courier
              New,Courier,monospace">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.<br>
              <br>
              Rémi<br>
              <br>
              ----- Mail original -----<br>
              > De: "Brian Goetz" <a class="moz-txt-link-rfc2396E" href="mailto:brian.goetz@oracle.com"><brian.goetz@oracle.com></a><br>
              > À: "Bjorn B Vardal" <a class="moz-txt-link-rfc2396E" href="mailto:bjornvar@ca.ibm.com"><bjornvar@ca.ibm.com></a><br>
              > Cc: <a class="moz-txt-link-abbreviated" href="mailto:valhalla-spec-experts@openjdk.java.net">valhalla-spec-experts@openjdk.java.net</a><br>
              > Envoyé: Mardi 23 Février 2016 01:23:16<br>
              > Objet: Re: Classes, specializations, and statics<br>
              ><br>
              > It's possible that there could be multiple "ssinit"
              methods, each<br>
              > restricted to specific parameterizations (just like
              any other restricted<br>
              > method), but in general, the "ssinit" method can be
              specialized just<br>
              > like any other method.  So what I envision (in the
              absence of<br>
              > initialization of conditional members) is possibly
              two such methods; one<br>
              > that is specializable (corresponding to _SS members)
              and one that is<br>
              > not, restricted to the erased parameterization
              (corresponding to<br>
              > traditional statics.)<br>
              ><br>
              ><br>
              ><br>
              > On 2/22/2016 4:11 PM, Bjorn B Vardal wrote:<br>
              > > I think we're on the same page regarding
              specialized <clinit>.<br>
              > >  - The JVM will be handed multiple
              <clinit> partial methods, and the<br>
              > > specializer will take care of selecting the
              appropriate <clinit> for<br>
              > > each specialization.<br>
              > >  - The erased <clinit> will contain the
              non-specialized static<br>
              > > initialization code, which ensures that it only
              runs once.<br>
              > >  - The erased <clinit> will always run
              before the first specialization<br>
              > > <clinit>.<br>
              > >  - The Java syntax is still up for discussion.<br>
              > > > I think this is mostly a matter of coming
              up with the right syntax,<br>
              > > which makes it clear that statics can be
              per-class or<br>
              > > per-specialization.  There are a whole pile of
              related<br>
              > > specialization-related syntax issues, I'll try
              to get them all in one<br>
              > > place.<br>
              > > I don't think the problem will be to make it
              clear that statics can be<br>
              > > per-class or per-specialization, but rather why
              some parameterizations<br>
              > > (which to the user are synonymous with
              specializations) don't appear<br>
              > > to have specialized statics. Do we want to put
              erasure in the face of<br>
              > > users like this? It seems better to let the
              users deal purely with<br>
              > > parameterizations, and we let specialization and
              erasure be<br>
              > > implementation details.<br>
              > > --<br>
              > > Bjørn Vårdal<br>
              > ><br>
              > >     ----- Original message -----<br>
              > >     From: Brian Goetz
              <a class="moz-txt-link-rfc2396E" href="mailto:brian.goetz@oracle.com"><brian.goetz@oracle.com></a><br>
              > >     To: Bjorn B Vardal/Ottawa/IBM@IBMCA,<br>
              > >     <a class="moz-txt-link-abbreviated" href="mailto:valhalla-spec-experts@openjdk.java.net">valhalla-spec-experts@openjdk.java.net</a><br>
              > >     Cc:<br>
              > >     Subject: Re: Classes, specializations, and
              statics<br>
              > >     Date: Thu, Feb 18, 2016 7:55 PM<br>
              > ><br>
              > ><br>
              > >>     Based on the example above, I think we
              need to be more explicit<br>
              > >>     about how the <clinit> method is
              handled.<br>
              > >>     There are really two different sets of
              statics that need to be<br>
              > >>     handled by the class initialization:<br>
              > >>     A) common statics (shared across all
              instantiations)<br>
              > >>     B) specialized statics<br>
              > >>     In addition to the statics, there is
              also common (and maybe<br>
              > >>     specialized?) code that is run as part
              of <clinit>.<br>
              > ><br>
              > >     There is a reasonable model to collapse
              these back into one<br>
              > >     concept; treat "common statics" as
              specialized statics on the<br>
              > >     all-erased parameterization, with a
              <where> clause that restricts<br>
              > >     them to that parameterization.  Not clear
              whether we actually want<br>
              > >     to represent it that way or not, but its a
              useful mental model<br>
              > >     that doesn't require the creation of a third
              thing.  (Since<br>
              > >     Class[Foo] and ParamType[Foo,erased*]
              describe the same class,<br>
              > >     this is also fully binary compatible with
              existing classes.)<br>
              > ><br>
              > >     Which means we can do a similar thing with
              <clinit>, if we want.<br>
              > >     I'll wave my hands because we've not yet
              talked much about<br>
              > >     conditional members, but it basically looks
              like this:<br>
              > ><br>
              > >     <where T*=erased*><br>
              > >     <init>() { /* common static init code
              */<br>
              > >                    /* specializable init code */
              }<br>
              > ><br>
              > >     <init>() { /* specializable init code
              */ }<br>
              > ><br>
              > >     Or not.<br>
              > >>     Where will the initialization code for
              both kinds of statics be?<br>
              > >>      The existing <clinit> method?<br>
              > ><br>
              > >     We have two choices:<br>
              > >      - have a new <sclinit> block that
              gets run once per<br>
              > >     specialization, and keep <clinit><br>
              > >      - merge the two as above, exploiting
              planned support for<br>
              > >     conditional members<br>
              > ><br>
              > >     Either way, as you say, we have to ensure
              that the common init<br>
              > >     runs exactly once.<br>
              > >>     When using *static, are we only
              discussing {get,put}?  Or is this<br>
              > >>     also proposing invokestatic changes to
              allow specialized static<br>
              > >>     methods?<br>
              > ><br>
              > >     Methods too.<br>
              > >>     All of the technical details aside, is
              this something we really<br>
              > >>     want to expose to the users?  They're
              going to have a hard time<br>
              > >>     understanding why Foo<int> (or
              Foo<ValueType) gets specialized<br>
              > >>     statics while Foo<String> &
              Foo<Bar> share the erased version.<br>
              > ><br>
              > >     I think this is mostly a matter of coming up
              with the right<br>
              > >     syntax, which makes it clear that statics
              can be per-class or<br>
              > >     per-specialization.  There are a whole pile
              of related<br>
              > >     specialization-related syntax issues, I'll
              try to get them all in<br>
              > >     one place.<br>
              > ><br>
              > ><br>
              ><br>
              > </font><br>
             </div>
        </blockquote>
        <div dir="ltr"> </div>
      </div>
      <br>
    </blockquote>
    <br>
  </body>
</html>