>Conservatively, when implementing a JavaScript runtime in Java, anything known to be a number can be represented in Java as a double, and everything else can be represented as an Object.
sounds like beginning of a horror story.
>and that's where optimistic type system comes in. Our optimistic type system works by assuming that any statically unprovable type is an int, the narrowest possible of all types. If this turns out to be wrong at runtime, e.g. we load a field from memory/scope that turned out to be an Object or a double instead, or if we perform a 32-bit addition that overflows, we will replace the executing code with a more conservative version, that is regenerated on the fly.
i hope all that heroism and effort has a good reason for it beside just being a great/interesting engineering endeavor.
"I read that and wondered why they don't default to a double, instead of an int? Double is javascripts internal type so the effort seems wasted."
Ints take up less space and often take less cycles to perform arithmetic on - so if you can use an int rather than a double it's generally going to be faster.
I can't immediately prove it, but I would imagine that if you modify the source of a JS implementation like Nashorn or V8 to remove int from the type lattice, you will find many programs run dramatically slower.
A lot of JavaScript optimizations use 32-bit ints internally, specifically bitwise operations will truncate to a 32-bit value before performing any such operations... not to mention improved cpu overhead and benefits from the asm.js subset.
> Indeed, the amount effort put into optimizing dynamic languages boggles the mind
It is actually quite interesting, given that was the research in optimizing Lisp and Smalltalk runtimes that gave birth to JIT compilers and many of their techniques.
What I find sad is the effort being spent in JavaScript, instead of more optimizer friendly languages like Lisp and Dylan.
But that is what we got in mainstream languages and why I am following Julia's progress.
do you have any experience creating a jit complier for a dynamic language? If you don't, you should not be commenting on this, nobody needs your input. If you do happen to be an expert, please point us to journal articles that explain a better way.
sounds like beginning of a horror story.
>and that's where optimistic type system comes in. Our optimistic type system works by assuming that any statically unprovable type is an int, the narrowest possible of all types. If this turns out to be wrong at runtime, e.g. we load a field from memory/scope that turned out to be an Object or a double instead, or if we perform a 32-bit addition that overflows, we will replace the executing code with a more conservative version, that is regenerated on the fly.
i hope all that heroism and effort has a good reason for it beside just being a great/interesting engineering endeavor.