Static fields and specialization

[MacGregor, Duncan (GE Energy Management)]

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

From: Palo Marton <palo.marton at gmail.com<mailto:palo.marton at gmail.com>>
Date: Monday, 12 January 2015 13:41
To: Duncan MacGregor <duncan.macgregor at ge.com<mailto:duncan.macgregor at ge.com>>
Cc: Richard Warburton <richard.warburton at gmail.com<mailto:richard.warburton at gmail.com>>, valhalla-dev <valhalla-dev at openjdk.java.net<mailto:valhalla-dev at openjdk.java.net>>
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
initialisation.

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();
        }
}

Duncan.

On 12/01/2015 12:51, "Palo Marton" <palo.marton at gmail.com<mailto:palo.marton at gmail.com>> 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.
>
>
>
>
>
>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>
>>>
>>
>>