I think the complexity of CLR+JVM+languages ontop+system libs+community libs probably rivals the Joint Strike Fighter. I think the key is to not try to build *another* JSF. Leverage leverage leverage. :)
On Thu, Aug 22, 2013 at 2:55 PM, Jonathan S. Shapiro <[email protected]>wrote: > However, this link-and-load approach encourages a fight between >> polymorphism and performance. This is the wedge that's driving JIT into >> modern systems, as we desire both. >> > > I think that's a potential issue, but I go back and forth on how serious > it is. My suspicion is that if you can get aggressive inlining at ground > types - and I think you can - then most of the rest isn't that bad. > The trouble I see here, is that modular compilation pushes us towards polymorphic interface based programming where it starts to become more serious. Sticking to functional style really only works for whole program compiles where quasi-polymorphism is expressed in match/switch over variants. > You aren't going to get the ideal degree of inlining, but with virtual > functions you wouldn't get that in any case. > Why are virtual functions somehow a limit? Today's JVM and CLR can inline across virtual functions using polymorphic inline caching ala Hotspot/SELF. (aka, optimistic type-test and inlined code, with a fallback to the slow virtual function case) AFAIK, because of the optimistic type-test, this technique can be used the same way in AOT as in JIT, because if the inline type-test fails it just falls back to the actual virtual method call. It's just harder to figure out the actual types that appear via static analysis, so that typically needs some type of runtime profiling. > By my view the line between AOT and JIT is a fuzzy one. Some modern >> systems make use of runtime code generation (regex, sql, etc), if this is >> supported then JIT is effectively supported. >> > > I think you mean "it's fuzzy if you can get trace information and re-run > the AOT mechanism". I *almost* agree. > It's even fuzzy without trace-rerun. If I ask to dynload a module, the only difference between AOT and JIT is how long I have to wait before it starts running. (assuming the dynload doesn't invalidate something the AOT can't handle) What *you* are saying is that we can run AOT on assembly Y as late as load >>> time. That's correct. >>> >> Yes, as long as it doesn't violate any AOT constraints. This is where adding type-tests to sanity check inlined code and polymorphic inline virtual method caches really helps, since it means dynloading a previously unknown AOT will still *work* it just won't necessarily be as fast as it could have been if the JIT could re-generate the inlined loop. What the second approach does not admit is run-time registration and >> loading of a *new-version* of an existing registered assembly -- since that >> would require stopping and recompiling the application. >> > > Yes. More precisely: a new version of a registered assembly such that the > portion of the interface consumed by the loading program has actually > changed. If you are really designing for dynamic loading, you work pretty > hard to keep that interface type stable, because (as you say) > type-redefinition is a mess of problems. > Yes, exactly.
_______________________________________________ bitc-dev mailing list [email protected] http://www.coyotos.org/mailman/listinfo/bitc-dev
