

Nashorn Architecture and Performance Improvements in Upcoming Release - swannodette
https://blogs.oracle.com/nashorn/entry/nashorn_performance_work_in_the

======
trhway
>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.

~~~
marktangotango
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.

>>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).

~~~
chrisseaton
"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.

------
SerCe
One day nashorn on jvm would be faster then V8.

~~~
randomfool
Why?

