Nashorn Architecture and Performance Improvements in Upcoming Release
blogs.oracle.com
blogs.oracle.com
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 hope all that heroism and effort has a good reason for it beside just being a great/interesting engineering endeavor.
Indeed, the amount effort put into optimizing dynamic languages boggles the mind, particularly on the jvm (including all the work on invoke dynamic).
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.
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.