Static fields and specialization

[Palo Marton]

> Oh, they’re definitely evil, but they probably still need to be supported.
>

You folks probably live in highly multithreaded world ;-) But there still
exists some single threaded apps or people who don't care much about issues
surrounding multitrheaded access. You can find some example of mutable
static field here:

class Loader<T> {
    private static int thingsLoaded;

    T load(String name) {
        ++thingsLoaded;
        // load and return the thing
    }

    int getLoadCount() { return thingsLoaded; }
}

(from http://cr.openjdk.java.net/~briangoetz/valhalla/specialization.html).




> From: Rémi Forax <forax at univ-mlv.fr<mailto:forax at univ-mlv.fr>>
> Date: Monday, 12 January 2015 13:40
> To: Duncan MacGregor <duncan.macgregor at ge.com<mailto:
> duncan.macgregor at ge.com>>, "valhalla-dev at openjdk.java.net<mailto:
> valhalla-dev at openjdk.java.net>" <valhalla-dev at openjdk.java.net<mailto:
> valhalla-dev at openjdk.java.net>>
> Subject: Re: Static fields and specialization
>
>
> 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><mailto:
> 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
> ><mailto: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<http://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><
> http://twitter.com/richardwarburto>
>
>