Static fields and specialization

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


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

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