Re:Performance Tuning for .NET Core
by chrisseaton on Tuesday January 15, 2019 @03:06PM
(#18914504)
Why doesn't the JIT assume classes are effectively sealed until it sees a subclass, like the JVM does.
[ Parent
| on HN ]
Because AFAIK .net cannot deopt when another implementation is loaded dynamically
I think Core 3.0 can?
Because it is bad design known as fragile base class, which usually leads to hard to track down bugs, because someone somewhere is accessing methods or internal class data structures that they shouldn't have to in first place.
Re:Performance Tuning for .NET Core
by chrisseaton on Tuesday January 15, 2019 @03:32PM
(#18914803)
That sounds more like an argument to seal your classes, rather than for why the JIT doesn't, in addition to that, assume classes as sealed until proved otherwise.
You're talking about the programming model, where I'm talking about the implementation.
Well, JIT heuristics end up being designed to live with the typical code patterns of the programming language.
In Java's case, since methods are virtual by default so with open classes a large majority of the code has a possible indirection, hence such optimizations.