Converting from JFX Webview to Nashorn. Performance trouble

[Jenks, Robert]

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<mailto:marcus.lagergren at oracle.com>>
Date: Saturday, October 25, 2014 at 1:41 PM
To: Robert Jenks <rjenks at ti.com<mailto:rjenks at ti.com>>
Cc: "Jim Laskey (Oracle)" <james.laskey at oracle.com<mailto:james.laskey at oracle.com>>, "nashorn-dev at openjdk.java.net<mailto:nashorn-dev at openjdk.java.net>" <nashorn-dev at openjdk.java.net<mailto: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<mailto: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<mailto: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<mailto: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