Can we also get some feedback on specialization, please?

[MacGregor, Duncan (GE Energy Management)]

Ah, I hadn't realised static methods could be specialised… that probably need to be called out in Brain's doc in the Statics section.

As Remi has said the class value approach doesn't produce something that is a constant, and nor does the CHM method, so I would not expect either to be a good basis for performant code, at least at this time.

Maybe statics on the specialised classes isn't the right answer, but there are good reasons for wanting to be able to specialise static fields in some way, especially final ones which can be seen by the JIT to be constant. Maybe allow the addition of type variables to their declaration and reference?

Duncan
________________________________________
From: valhalla-dev [valhalla-dev-bounces at openjdk.java.net] on behalf of Peter Levart [peter.levart at gmail.com]
Sent: 10 January 2015 13:39
To: Remi Forax; valhalla-dev at openjdk.java.net
Subject: Re: Can we also get some feedback on specialization, please?

On 01/10/2015 10:58 AM, Remi Forax wrote:
>
> On 01/10/2015 04:49 AM, Brian Goetz wrote:
>> You might look at ClassValue as a means for this sort of per-class
>> static constants?
>
> The result of ClassValue.get() with a constant class is not a constant
> at least with the current implementation.
>
> Rémi

The alternative is to use the class literal as a key into CHM for example:

class HolderClass<any T> {
     static final ConcurrentMap<Class<?>, X> constants = new CHM<>();

     static <any T> X getConstant() {
         return constants.computeIfAbsent(HolderClass<T>.class, (c) -> {
... });
     }


See also here, when you know the values for all specializations upfront:

http://cr.openjdk.java.net/~plevart/misc/valhala-hacks/util/AnyHelper.java


Regards, Peter

>
>>
>> On 1/9/2015 10:47 PM, MacGregor, Duncan (GE Energy Management) wrote:
>>> And another thing...
>>>
>>> If I want to try and combine the use of VarHandles and specialisation
>>> to make something with atomic properties (as I'm sure we'll all want
>>> to do for concurrent collections) then at the moment I can't use
>>> static fields for the var handles, and the JIT is almost certainly
>>> going to hate me if I they are stored on instance fields. I think
>>> we'll need some way to specify static fields as specialised and
>>> provide initialisers for them. This cannot be done by simply having
>>> different statics for different layers since each specialised class
>>> will need it's own statics.
>>>
>>> I'm sure there's also some evil I can perpetrate by specialising
>>> CallSites, but I haven't though of a really convincing case for doing
>>> so yet (at least not until I can define typed tuples when I can maybe
>>> replace various varargs fallbacks), and I hit the same statics
>>> problem as above with MethodHandles anyway.
>