Static fields and specialization

MacGregor, Duncan (GE Energy Management) duncan.macgregor at ge.com
Mon Jan 12 13:45:19 UTC 2015


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

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>



More information about the valhalla-dev mailing list