Static fields and specialization

MacGregor, Duncan (GE Energy Management) duncan.macgregor at
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<mailto:palo.marton at>>
Date: Monday, 12 January 2015 13:54
To: Duncan MacGregor <duncan.macgregor at<mailto:duncan.macgregor at>>
Cc: Rémi Forax <forax at<mailto:forax at>>, "valhalla-dev at<mailto:valhalla-dev at>" <valhalla-dev at<mailto:valhalla-dev at>>
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) {
        // load and return the thing

    int getLoadCount() { return thingsLoaded; }


From: Rémi Forax <forax at<mailto:forax at><mailto:forax at<mailto:forax at>>>
Date: Monday, 12 January 2015 13:40
To: Duncan MacGregor <duncan.macgregor at<mailto:duncan.macgregor at><mailto:duncan.macgregor at<mailto:duncan.macgregor at>>>, "valhalla-dev at<mailto:valhalla-dev at><mailto:valhalla-dev at<mailto:valhalla-dev at>>" <valhalla-dev at<mailto:valhalla-dev at><mailto:valhalla-dev at<mailto:valhalla-dev at>>>
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 ?


On 12/01/2015 13:26, "Remi Forax" <forax at<mailto:forax at>><mailto:forax at<mailto:forax at>> 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
object on heap (eg Variable<T>) and returm get/set MethodHandle for that

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.


On Mon, Jan 12, 2015 at 12:44 PM, Palo Marton <palo.marton at<mailto:palo.marton at>><mailto:palo.marton at<mailto:palo.marton at>>

Yes, but you can not create specialized implementations for user
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:
will have to write separate code for each primitive type.

Pavol Marton, aSc<><>

In the case of Optional.empty() and others like
it's a method that you're invoking. There is no need to implement
field specialization. You can just get your specialized
implementations to
return different singleton instances. Ok - so this means you now have
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
so its really 9 rather than 4 anyway.


   Richard Warburton
   @RichardWarburto <><>

More information about the valhalla-dev mailing list