Static fields in specialized classes

Brian Goetz brian.goetz at oracle.com
Tue Oct 14 13:36:15 UTC 2014


> 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