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 <[email protected]> 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)" <[email protected] > <mailto:[email protected]>> > 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 <[email protected]> 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
