6 ms·

Value types aren't "necessary", but they would have been valueable at day 1. The GC heap is simply inefficient; not necessarily because of the GC (which indeed

by emn13 7y ago

Value types aren't "necessary", but they would have been valueable at day 1. The GC heap is simply inefficient; not necessarily because of the GC (which indeed is harder with massive multicore), but simply because of the per-object memory overhead. There's a reason java had built-in value types from day 1, because it made sense even back then. Frankly, I think both java and C# kind of got this wrong. There was an overreaction against the C/C++ of the day, and whereas the GC turned out brilliant, the idea that it's not even necessary to express the notion of references/pointers/values etc. was too much; and the idea of a single type system root (object) is similarly dubious, and then particularly the idea that that root type isn't the empty type. Object has semantics, and that was a mistake, because it contributes to the bloat. I'm totally happy with ignoring those features 99.9% of the time, but having them completely unavailable makes those 0.1% cases extremely expensive. (I mean, I think those things are slightly changing, but it's slow going).

pjmlp 7y ago
C# got it right from day one, regarding value types. AOT compilation not so much, given the NGEN constraints. However they got it both wrong, considering CLU, Modula-3, Delphi and Eiffel are considered influencial languages on their design.
- pron 7y ago
  Mutable structs are not exactly value types, but Microsoft has always preferred control over simplicity (after all, they pushed C++ really hard). I won't say whether that philosophy is right or wrong, but it is very different from Java's.
pron 7y ago
> because it made sense even back then. That was necessary for performance back then. User-defined value types weren't, and Java has done well without them. > Object has semantics, and that was a mistake, because it contributes to the bloat. I think most of the RAM bloat is due to the GC trading off extra RAM for speed rather than object headers, and I'm not sure trading off complexity for headers was right 25 years ago (JS is doing fine on the client without value types). What changed was the performance characteristics. As to object semantics, it may be a fixable mistake. The goal is to get value types without today's object semantics while preserving a single class hierarchy at the same time. The Valhalla team thinks that's achievable.
- pjmlp 7y ago
  I advise you to read Mesa/Cedar report on the impact of garbage collection algorithms available at Xerox PARC bitsavers archive, EthOS or SpinOS experience with Modula-3. All of them refer that having value types alongside GC had a relevant impact improving performance. All systems designed before Java was a thing. Or since you refer to JS, the paper about SELF's design. Even Dylan was designed with AOT/JIT and value types support, which is relevant here given that its domain was being a systems language for the Newton. That politics killed it is another matter.
  - pron 7y ago
    Oh, I don't deny that value types would have helped performance back in '95, just that they were absolutely essential for Java. Smalltalk/Self and Scheme/CL didn't have them, and those were probably Java's greatest influences; I don't think VB had them, either. Also, in its first four years, before HotSpot was ready, Java was interpreted, so it had bigger performance problems. I don't know why there was no emphasis on AOT back then. I guess they started with interpreter/JIT, and then there just wasn't much demand for AOT until now.
    - pjmlp 7y ago
      Microsoft Basics have support for value types since MS-DOS. QuickBasic supported value types and AOT to native code, and while Visual Basic used P-Code, version 6 introduced a proper AOT native compiler. Modula-3 was also a big influence, at least accordingly to some papers. There was surely demand for AOT, given that most commercial JVMs had it in some form or the other since 2000. Even Sun actually supported it in Java Embedded variant for OEMs, probably grudgingly. Common Lisp certainly has support for value types.
      - pron 7y ago
        What user-defined value types did CL have in '95? Also, are you sure about VB having had them then? As for AOT, there may not have been sufficient demand from Sun/Oracle. I only joined relatively recently, but we generally do expensive things only if we believe they have a huge benefit or in huge demand, and we believe it can be long-lasting. The assumption is that any new feature will require maintenance for 20 years, taking away resources from other things. So if something is expensive, even if it's cool or some people could find it very useful -- we don't do it. The assumption is that the ecosystem is large enough that others can, and will.

by emn13 7y ago

pjmlp 7y ago

C# got it right from day one, regarding value types. AOT compilation not so much, given the NGEN constraints. However they got it both wrong, considering CLU, Modula-3, Delphi and Eiffel are considered influencial languages on their design.

pron 7y ago
Mutable structs are not exactly value types, but Microsoft has always preferred control over simplicity (after all, they pushed C++ really hard). I won't say whether that philosophy is right or wrong, but it is very different from Java's.

pron 7y ago

> because it made sense even back then. That was necessary for performance back then. User-defined value types weren't, and Java has done well without them. > Object has semantics, and that was a mistake, because it contributes to the bloat. I think most of the RAM bloat is due to the GC trading off extra RAM for speed rather than object headers, and I'm not sure trading off complexity for headers was right 25 years ago (JS is doing fine on the client without value types). What changed was the performance characteristics. As to object semantics, it may be a fixable mistake. The goal is to get value types without today's object semantics while preserving a single class hierarchy at the same time. The Valhalla team thinks that's achievable.

pjmlp 7y ago
I advise you to read Mesa/Cedar report on the impact of garbage collection algorithms available at Xerox PARC bitsavers archive, EthOS or SpinOS experience with Modula-3. All of them refer that having value types alongside GC had a relevant impact improving performance. All systems designed before Java was a thing. Or since you refer to JS, the paper about SELF's design. Even Dylan was designed with AOT/JIT and value types support, which is relevant here given that its domain was being a systems language for the Newton. That politics killed it is another matter.
- pron 7y ago
  Oh, I don't deny that value types would have helped performance back in '95, just that they were absolutely essential for Java. Smalltalk/Self and Scheme/CL didn't have them, and those were probably Java's greatest influences; I don't think VB had them, either. Also, in its first four years, before HotSpot was ready, Java was interpreted, so it had bigger performance problems. I don't know why there was no emphasis on AOT back then. I guess they started with interpreter/JIT, and then there just wasn't much demand for AOT until now.
  - pjmlp 7y ago
    Microsoft Basics have support for value types since MS-DOS. QuickBasic supported value types and AOT to native code, and while Visual Basic used P-Code, version 6 introduced a proper AOT native compiler. Modula-3 was also a big influence, at least accordingly to some papers. There was surely demand for AOT, given that most commercial JVMs had it in some form or the other since 2000. Even Sun actually supported it in Java Embedded variant for OEMs, probably grudgingly. Common Lisp certainly has support for value types.
    - pron 7y ago
      What user-defined value types did CL have in '95? Also, are you sure about VB having had them then? As for AOT, there may not have been sufficient demand from Sun/Oracle. I only joined relatively recently, but we generally do expensive things only if we believe they have a huge benefit or in huge demand, and we believe it can be long-lasting. The assumption is that any new feature will require maintenance for 20 years, taking away resources from other things. So if something is expensive, even if it's cool or some people could find it very useful -- we don't do it. The assumption is that the ecosystem is large enough that others can, and will.