Static fields and specialization

Mon Jan 12 14:00:41 UTC 2015

I’d tend to make that a final atomic integer, but I can easily imagine it being does as a volatile int and some var handle stuff to handle the increment.

Though I have used a plain int when I know thread safety won’t be an issue.

From: Palo Marton <palo.marton at gmail.com<mailto:palo.marton at gmail.com>>
Date: Monday, 12 January 2015 13:54
To: Duncan MacGregor <duncan.macgregor at ge.com<mailto:duncan.macgregor at ge.com>>
Cc: Rémi Forax <forax at univ-mlv.fr<mailto:forax at univ-mlv.fr>>, "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

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><mailto: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><mailto:duncan.macgregor at ge.com<mailto:duncan.macgregor at ge.com>>>, "valhalla-dev at openjdk.java.net<mailto:valhalla-dev at openjdk.java.net><mailto: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><mailto: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>><mailto: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>><mailto: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><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>