Can we also get some feedback on specialization, please?

[Peter Levart]

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