Static fields and specialization

Palo Marton palo.marton at
Mon Jan 12 12:51:11 UTC 2015

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

On Mon, Jan 12, 2015 at 12:44 PM, Palo Marton <palo.marton at> 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
>> 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
>>   @RichardWarburto <>

More information about the valhalla-dev mailing list