Static fields and specialization

MacGregor, Duncan (GE Energy Management) duncan.macgregor at
Mon Jan 12 13:52:49 UTC 2015

Good point, using a function to fetch the value should be fine.

From: Palo Marton <palo.marton at<mailto:palo.marton at>>
Date: Monday, 12 January 2015 13:41
To: Duncan MacGregor <duncan.macgregor at<mailto:duncan.macgregor at>>
Cc: Richard Warburton <richard.warburton at<mailto:richard.warburton at>>, valhalla-dev <valhalla-dev at<mailto:valhalla-dev at>>
Subject: Re: Static fields and specialization

That sounds fundamentally okay, but probably also requires a typed static
initialiser syntax for fields that could throw an exception during

You can wrap such initialization to generic method by yourself:

static final <any T> MethodHandle mh=mh_init();

static <any T> MethodHandle mh_init() {.....throw...}

Supporting "<any T> static {... }" will bring many challenges with order of execution for such initializes.

Something like

static final <any T> MethodHandle mh;

static <any T> {
        try {
                // Do MethodHandle lookup
        } (catch e) {
                Throw new Error();


On 12/01/2015 12:51, "Palo Marton" <palo.marton at<mailto:palo.marton at>> 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
>On Mon, Jan 12, 2015 at 12:44 PM, Palo Marton <palo.marton at<mailto:palo.marton at>>
>> 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:
>> will have to write separate code for each primitive type.
>> Pavol Marton, aSc
>>> 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
>>> 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
>>> so its really 9 rather than 4 anyway.
>>> regards,
>>>   Richard Warburton
>>>   @RichardWarburto <>

More information about the valhalla-dev mailing list