Re: Static fields and specialization

[Timo Kinnunen]

They’re fine as long as you never change them from multiple threads at the same time (and why would you do that..?)









-- 
Have a nice day,
Timo.

Sent from Windows Mail





From: Remi Forax
Sent: ‎Monday‎, ‎January‎ ‎12‎, ‎2015 ‎14‎:‎40
To: MacGregor, Duncan (GE Energy Management), valhalla-dev at openjdk.java.net






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> 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>
>>>>>