Can we also get some feedback on specialization, please?

[MacGregor, Duncan (GE Energy Management)]

There's that, and also the issue that the computeValue method will then have to use reflection to work out the specialised types. Equally I think we should consider how to support classes that want to both specialise and intern values by providing methods alongs the lines of

MyType<T>.myType(T t, ...) {
}

it certainly feels like something you should be able to do.

Along similar lines, is there a proposal on how to handle specialised collections and things like

public static <T> Set<T> singleton(T o)

from Collections if statics are not allowed to be specialised over any T.

Duncan.

________________________________________
From: valhalla-dev [valhalla-dev-bounces at openjdk.java.net] on behalf of Remi Forax [forax at univ-mlv.fr]
Sent: 10 January 2015 09:58
To: valhalla-dev at openjdk.java.net
Subject: Re: Can we also get some feedback on specialization, please?

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

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