Static fields and specialization

[Remi Forax]

On 01/12/2015 02:46 PM, Timo Kinnunen wrote:
> They’re fine as long as you never change them from multiple threads at 
> the same time (and why would you do that..?)

and you can not test any code that depend on it easily
and if the type is an object you keep an objects graph forever in memory.

pure evil as i said.

Rémi

>
>
>
>
> -- 
> Have a nice day,
> Timo.
>
> Sent from Windows Mail
>
> *From:* Remi Forax <mailto:forax at univ-mlv.fr>
> *Sent:* ‎Monday‎, ‎January‎ ‎12‎, ‎2015 ‎14‎:‎40
> *To:* MacGregor, Duncan (GE Energy Management) 
> <mailto:duncan.macgregor at ge.com>, valhalla-dev at openjdk.java.net 
> <mailto:valhalla-dev at openjdk.java.net>
>
>
> On 01/12/2015 02:29 PM, MacGregor, Duncan (GE Energy Management) wrote:
> > You won¹t need any holder for a _final_ static with a type variable, but
> > non-final statics would definitely require a holder.
>
> On 01/12/2015 02:29 PM, Palo Marton wrote:
> >
> >     You don't need any holder, there is a special MethodHandle
> >     named MethodHandles.constant() which is able to always
> >     return the same value, the JIT will consider the value as a true
> >     constant.
> >
> >
> > Yes, that can be optimization for final fields. You need holder just
> > for non-final fields.
>
> Am i the only one to live in a world where static non final field are
> considered as evil ?
>
> Rémi
>
> >
> > On 12/01/2015 13:26, "Remi Forax" <forax at univ-mlv.fr> wrote:
> >
> >> On 01/12/2015 01:51 PM, Palo Marton wrote:
> >>> One possible solution how to support specialized static fields is 
> to use
> >>> same approach as with generic methods. E.g. with this syntax:
> >>>
> >>> private static final <any T> Optional<T> EMPTY = new Optional<T>();
> >>>
> >>> This will compile initializing expression to generic static method:
> >>>
> >>> private static <any T> Optional<T> EMPTY$init() {
> >>>      return  new Optional<T>();
> >>> }
> >>>
> >>> And all get/set access to EMPTY<T> will use invocedynamic. 
> Bootsrap will
> >>> call Optional.<T>EMPTY$init() to get initial value, store it in some
> >>> holder
> >>> object on heap (eg Variable<T>) and returm get/set MethodHandle 
> for that
> >>> field.
> >> You don't need any holder, there is a special MethodHandle
> >> named MethodHandles.constant() which is able to always
> >> return the same value, the JIT will consider the value as a true 
> constant.
> >>
> >> Rémi
> >>
> >>>
> >>>
> >>>
> >>>
> >>> On Mon, Jan 12, 2015 at 12:44 PM, Palo Marton <palo.marton at gmail.com>
> >>> wrote:
> >>>
> >>>> Yes, but you can not create specialized implementations for user
> >>>> defined
> >>>> value types. So these will be left with much slower implementation.
> >>>> Singleton implementation compiles to just 0-1 instructions and
> >>>> implementation that allocates new instance will be much slower.
> >>>>
> >>>> And other problem - such approach is against goals of specialization:
> >>>> You
> >>>> will have to write separate code for each primitive type.
> >>>>
> >>>> Pavol Marton, aSc
> >>>> www.asctimetables.com
> >>>>
> >>>>
> >>>>> In the case of Optional.empty() and others like
> >>>>> Collections.emptyList()
> >>>>> it's a method that you're invoking. There is no need to implement
> >>>>> static
> >>>>> field specialization. You can just get your specialized
> >>>>> implementations to
> >>>>> return different singleton instances. Ok - so this means you now 
> have
> >>>>> 9
> >>>>> empty instances rather than 1 but that's basically nothing in 
> terms of
> >>>>> memory consumption. In the case of Optional you already have manual
> >>>>> specialisation for 3 primitive cases in the form of Optionalint and
> >>>>> friends
> >>>>> so its really 9 rather than 4 anyway.
> >>>>>
> >>>>> regards,
> >>>>>
> >>>>>     Richard Warburton
> >>>>>
> >>>>>     http://insightfullogic.com
> >>>>>     @RichardWarburto <http://twitter.com/richardwarburto>
> >>>>>
>