The type work is somewhat interesting. I've actually seen variants of it done in a few private JIT's for dynamic languages, but not to this extent (mainly because most languages don't have code that change types as often as javascript :P). In the worst case, they still have to monitor every property write, they just use some forms of static analysis to try to reduce this in what they hope is the common case (that the types are not changing over the program lifetime).
The rest is just research.
Interesting research nonetheless, but research.
I don't say that as a dig, more to point out that while some of it may be productionized, most of it probably won't.
At least to me, i'm most impressed that the author doesn't present their research as the be-all, end-all of JIT's, but instead, something that may turn out well.
This is not something against JIT research, i've just read way too many compiler analysis and optimization papers that don't actually compare against anywhere the near the state of the art, and then act as if they've made huge gains instead of incremental improvements.
They optimize away unnecessary monitoring inside the traces once the types have been propagated there. So only slow path code does the monitoring. All the active traces should get stable types without extra monitoring at some point.
Essentially it's moving doing type propagation in "batch"
to a "dynamic trigger" system. How effective that is really depends on the programs (or the programing style) and how often they really change types.
I hope it's not just optimized for the usual benchmarks, but some real code.
It varies.
Remember that generational GC's used to write barrier and process every memory write into GC space, and that wasn't truly horrible for performance.
The rest is just research. Interesting research nonetheless, but research. I don't say that as a dig, more to point out that while some of it may be productionized, most of it probably won't.
At least to me, i'm most impressed that the author doesn't present their research as the be-all, end-all of JIT's, but instead, something that may turn out well. This is not something against JIT research, i've just read way too many compiler analysis and optimization papers that don't actually compare against anywhere the near the state of the art, and then act as if they've made huge gains instead of incremental improvements.