It’s hard to say that when we’re still clamouring for generics without type-erasure. It’s been over 14 years since the CLR had it and it’s definitely holding back the Java ecosystem in my opinion.
Erased generics are awesome. Without erasure interop and code sharing among languages with different variance strategies is severely hampered. It's because Java erases generics (for subclassable reference types) that Java, Kotlin and Clojure can all share the same data structures without any runtime conversions.
I imagine it would help to keep binary size and compile times down too, though I don't know by how much.
I wonder if C++ compilers "collapse" things like `vector<Foo⋆>` and `vector<Bar⋆>` (or even `vector<size_t>`) if they can figure out that all of their respective methods end up generating the same machine code... Maybe not?
(Stars because I can't seem to escape asterisks properly...)
This is a fairly common optimization that is normally performed by the linker. [0] is a blog entry that describes Microsoft’s implementation of identical function merging.
Ooh, really cool. The comment about function-pointer comparisons was a pretty funny ramification I hadn't considered too. Real "wtf" debugging case I bet.
I wonder what the standard says about it, what the linker can/could typically prove is "safe", and what performance/size changes are seen in practice.
The paper Safe ICF in Gold[0] says that they get between 4 to 7% savings on code size. A safer version that omits functions that have their address taken was 97% as effective.
The talk Diet Templates[1] has some suggestions for how to reduce template bloat.
You want to erase generics because you don't want to bake a specific variance model into your runtime. Erasing generics allows languages with different variance (e.g. Java, Kotlin and Clojure) to share code and data structures. This is not an issue for generics of non-subtypable types, which is why generics of the forthcoming value types will be specialized rather than erased.
Holding it back compared to what? I come from a CLR background and look enviously at the jvm ecosystem all the time. Haskell, BEAM, etc are almost all a step down from jvm once you factor in tooling.
I work with both, so I do agree with you with my C# hat on.
On the other hand with my Java hat on, I look enviously to proper unsigned types, value types, explicit SIMD, and the language support for low level coding optimizations.
Still looking forward for Valhalla and Panama to arrive.
No, it is not. Most JVM languages (except Ceylon, I think) choose to erase generics, as that's the right thing to do if you want good polyglot interop.
No, I mean that the JVM itself doesn’t have opcodes for storing generics type info. Hence why it was done for backward compatability, they didn’t need to add or change instructions.
That's incorrect. You could specialize classes on the fly (and the opcodes for all reference types are the same, anyway). It's just that it's a bad idea to reify generics of reference (and so subtypable) types. You gain little and lose much.
It’s hard to say that when we’re still clamouring for generics without type-erasure. It’s been over 14 years since the CLR had it and it’s definitely holding back the Java ecosystem in my opinion.