Static fields and specialization

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


You won¹t need any holder for a _final_ static with a type variable, but
non-final statics would definitely require a holder.

On 12/01/2015 13:26, "Remi Forax" <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>
>>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
>>>
>>>
>>>> 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>
>>>>
>>>
>



More information about the valhalla-dev mailing list