Static fields in specialized classes
Vitaly Davidovich
vitalyd at gmail.com
Tue Oct 14 14:29:01 UTC 2014
Thanks Brian. I agree that the end effect is what's most important; I was
using .NET as a concrete example since (a) it's a similar runtime/platform
to the JVM, (b) I find it well-thought out and (c) I'm familiar with it.
Looking forward to seeing what you guys come up with!
On Tue, Oct 14, 2014 at 9:36 AM, Brian Goetz <brian.goetz at oracle.com> wrote:
> In the CLR, the fact that structs get unique native code is a design
>> issue/restriction due to variable size of structs (refs are easy since
>> they're all same size pointers). In theory, structs of equal layout
>> could share machine code.
>>
>
> Its slightly more complicated than simply size -- you have to take into
> account whether the fields are refs or primitives as well (because the GC
> has to know where all the pointers are.) The minimal unit of sharing would
> be based on tuples of (n references, m bytes of non-references (modulo
> alignment requirements)). But we believe we have a path that will
> eventually get us to a higher degree of code sharing as well.
>
> How's this going to work for generic methods that are constrained to
>> take an interface type and thus allow structs/value types to be passed
>> in? Specifically, in .NET this allows avoiding boxing of struct
>> arguments. Is generic method specialization going to address that?
>>
>> Will reflection allow introspection of generic types and provide
>> information about the generic definition? Will it be possible to
>> instantiate a generic type specialization via reflection/late-binding?
>>
>
> All good questions; detailed answers will be answered in good time. Until
> then, the short answer is: if we couldn't avoid boxing, there's no point in
> doing specialization at all, and reflection support is part of doing
> language features.
>
> Finally, there's a neat use case in .NET regarding generic types and
>> static fields of that generic type. For example, there's a generic
>> abstract class called Comparer<T>. It has a property called Default,
>> which returns a Comparer<T> suitable for comparing T instances.
>> Internally, it decides what comparer to use by inspecting aspects of T.
>> The end result is you get a comparer that will avoid boxing of structs
>> if T is a struct. Is something like that going to work in what you guys
>> are thinking of?
>>
>
> Sure, it's a neat use case. (Does that make it a requirement? Absolutely
> not.) Note there's a difference between "can I write code with the effect
> as this C# code" and "can I write it exactly the same way as C#". I think
> the per-specialization static fields feature that you'd like is a massive
> loser. But the use case is valid, and I believe we'll get there by some
> other means.
>
>
More information about the valhalla-dev
mailing list