Converting from JFX Webview to Nashorn. Performance trouble

[Jim Laskey (Oracle)]

Thank you.

On Oct 27, 2014, at 3:43 PM, Jenks, Robert <rjenks at ti.com> wrote:

> I am working on the NDA and I think it should be possible.  If not, I will work on a relevant benchmark script.
> 
> Thanks for the info on the optimistic types. I will give that a try.
> 
> -Robert
> 
> From: Marcus Lagergren <marcus.lagergren at oracle.com>
> Date: Saturday, October 25, 2014 at 1:41 PM
> To: Robert Jenks <rjenks at ti.com>
> Cc: "Jim Laskey (Oracle)" <james.laskey at oracle.com>, "nashorn-dev at openjdk.java.net" <nashorn-dev at openjdk.java.net>
> Subject: Re: Converting from JFX Webview to Nashorn. Performance trouble
> 
> Any micro/minibenchmarks that you can extract would be very helpful indeed - i.e. those that have similar workloads like your code, but are NDA safe.
> 
> There are several performance improvements in the 8u40 if you run with —optimistic-types=true, at the cost of larger warmup (unless you use the code cache). That might help.
> 
> Regards
> Marcus
> 
>> On 24 Oct 2014, at 19:13, Jenks, Robert <rjenks at ti.com> wrote:
>> 
>> Unfortunately I cannot share code without an NDA, but let me ask up the
>> management ladder to see what they want to do.
>> 
>> I agree about Jav8.  Which is why it was lower priority than Nashorn to
>> test.  Fortunately there is very little interaction between Java and
>> Javascript needed for our app.
>> 
>> So without disclosing what I¹m working on, let me describe a similar
>> application.  Imaging that I am working on a GameBoy Emulator.  In this
>> case I would have a processor emulator written in Javascript and the ROM
>> as a byte array.  The only interaction needed are to inject key events and
>> to get screen updates using screen buffer in virtual memory (javascript
>> array).  Most of the Javascript is tiny functions which implement
>> processor opcodes.  These opcode functions are all annonymous and stored
>> in an array indexed by the opcode.
>> 
>> -Robert
>> 
>> On 10/24/14, 12:03 PM, "Jim Laskey (Oracle)" <james.laskey at oracle.com>
>> wrote:
>> 
>>> Robert,
>>> 
>>> Well, as with any port there has to be localized tweaking.  We'd be
>>> willing to help you profile and find the bottlenecks.  This also helps up
>>> find areas we need to improve.
>>> 
>>> Warning about JaV8, as far as I am aware there hasn't been a lot of
>>> activity on JaV8 of late.  The JNI support was very weak.
>>> 
>>> Cheers,
>>> 
>>> -- Jim
>>> 
>>> 
>>> 
>>> 
>>> On Oct 24, 2014, at 1:04 PM, Jenks, Robert <rjenks at ti.com> wrote:
>>> 
>>>> After getting back from JavaOne and being excited about Nashorn I
>>>> decided to try porting our large javascript app to work under Nashorn.
>>>> Currently we have a JavaFX application with a WebView component where we
>>>> load our HTML/CSS/Javascript application.  In WebView performance has
>>>> been about half of what we need it to be.  The Javascript application is
>>>> large, very CPU intensive.  It does draw to a canvas, but the drawing is
>>>> very simplistic and infrequent.
>>>> 
>>>> I completed the port and have been experimenting with it.  So far, I am
>>>> disappointed with the results.  I expected additional startup delays due
>>>> to the JIT, but even after the application is warmed up and the JIT
>>>> compilation threads go idle, the application is running about twice as
>>>> slow as the WebView version.  I even tried using Java 9 EA and it did
>>>> help some, but it¹s still no where near as fast.
>>>> 
>>>> I suspect that most of the performance advantages Nashorn gives are
>>>> related to using the Nashorn (Java) canvas implementation.  Since our
>>>> app isn¹t hindered by canvas performance, this doesn¹t help.  Another
>>>> interesting observation is that Nashorn is using a HUGE amount of heap
>>>> space.  Our app uses about 300-500MB using the WebView approach, but 3GB
>>>> under Nashorn.
>>>> 
>>>> So, unless someone has a suggestion I think I¹m going to move on to
>>>> trying to get V8 running through the Jav8 project.  Since our
>>>> application performs well in Chrome this is about the last option beyond
>>>> rewriting out app in C or Java.
>>>> 
>>>> -Robert
>