Seeking help back in the land of Rhino

[Remi Forax]

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