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