On 12/03/2013 02:34 PM, Tal Liron wrote:
That's reasonable. (I guess you're referring to the final death of the
permgen when you're talking about memory issues?)
So, what are your thoughts on the JVM7 port? Do you think it's
entirely non-viable? Pointless? Would result in a very poorly
performing engine?
The way the couple jdk/vm optimizes invokedynamic in jdk7 and jdk8 is
totally different.
The rewrite from scratch that occurs in jdk8 was triggered by several
things:
- performance, the old backend has some serious performance cliffs i.e.
you can have a code that perform well but a slightly modified code
will perform like it was interpreted only.
- correctness, invokedynamic allows you to perform other invokes like
invokestatic, invokevirtual, etc.
those bytecodes have a very precise semantics and the old
implementation doesn't fully reproduce the semantics.
If you want to port nashorn on jdk7 you will have to workaround those
bugs, while it's maybe possible,
you now know that the Hotspot guys had preferred to restart from scratch
instead of trying to fix those bugs.
The future: My burning wish item for Nashorn is to allow for the
generated bytecode to be portable, so that it could be cached (to
disk, etc.). Without this, for my use cases, Nashorn is actually a
noticeable step back from Rhino in terms of startup performance
(compilation is slower). Not sure how I could pitch in, exactly,
because that part of the code seems to be the stickiest and hardest to
penetrate... But perhaps if it becomes a milestone feature I can
assist in testing and patching.
cheers,
Rémi
On 12/03/2013 09:03 PM, Jim Laskey (Oracle) wrote:
There might be some aspects of that, but it is 99% technical. There
are some major changes required to the JVM to support Nashorn
properly in JDK 7 (perform well, no memory bloat, security et al.)
And then the question is, why don't we backport those changes to the
JVM? Well, then it becomes a slippery slope of interconnected
changes, JDK7 becomes JDK8, why are some people still using 1.4,
shouldn't we have a continuous update model, ...
The reality is, that groups who can't migrate from Rhino to Nashorn
right away, should take the time to do it right. Their users are
likely not early adopters. This gives Rhino projects time to mature
their migration properly and gives the Nashorn team time to respond
to feature requests need to migrate. The team is always listening
and willing to help out.
Speaking of which... Nashorn is locking down for JDK8 and planning
for the next releases. This is where y'all come in. Nashorn is Open
Source. Let us know what are your priorities. This also means those
willing and able to pitch in, should do so. If you have any ideas
you want to work on and push forward, let us know. If you want a
project to work on, I have a long list, let me know. Respond to this
list or me directly.
