Extremely slow startup performance

[Marcus Lagergren]

> 
> 1) By persistent code store, do you mean that the caching survive process restarts? That would be nice indeed.
> 
Yes I do. It will definitely survive restarts - including optimizations done and type assumptions (which will contribute to a warmup the first time too). These need not be done again. Attila - do you have anything to add here? Is it on be default. You can sync out the latest jdk9 repo and test it yourself.

> 2) What's the jit granularity? eval() ?
> 
We do read an entire script at once, but we don’t necessarily compile all of it (we do in 8u5 still, I think). With the lazy compilation policy we only compile the methods that we need in order to run the script when we encounter them. Sometimes it matters, sometimes it doesn’t. 

> 3) When will u40 be out? :)

New years, I think.  Check with the official lists. 

Poor man’s instrumentation; With 8u5 you can do -Dnashorn.time to get a system hook where the process spends its time. With 9 it’s —log=time.
Or send us a JFR recording. I would say that what you are looking at here is the pre-8u40 behavior of JITting the entire script. Likely you are going to
see code generation.  

Besides all that, if you need speed on “run 0” you’d need are further warmup improvements, which are not yet scheduled for a release.

> 
> Lang
> 
> 
> On Wed, Jul 2, 2014 at 12:18 PM, Marcus Lagergren <marcus.lagergren at oracle.com> wrote:
> Hi Lang!
> 
> We are aware of there being a couple of warmup issues in Nashorn. My guess is that “coffee-script.js” is a fairly large script, Nashorn currently compiles everything to byte code and therefore takes time.
> 
> In JDK9, the follow changes have already been checked in, that may help you:
> 
> * Lazy code generation policy on by default - less byte code generation
> * Class caching - reuse of compiled classes
> * Persistent code store on disk - basically identical code is never jitted more than once. If you compile identical source code, in these scripts, only the first run would be slow. This might help you out immensely. If you need the first run to go fast, we need to improve general warmup, and we are currently discussing how to do it. It’s on the table.
> 
> And the following that might make it a little bit worse, until we’ve had more time to property attack the warmup issues.
> 
> * Optimistic type optimization (may actually increase warmup)
> 
> These will be backported to 8u40.
> 
> What version of the JDK/nashorn are you using? Perhaps you could send us a Java Flight Recording of your recording of your slow startup, if you want us to look at it in detail. JFR files are always helpful.
> 
> Regards
> Marcus
> 
> On 02 Jul 2014, at 11:21, Sia Lang <silverlanguage at gmail.com> wrote:
> 
> > I'm trying to use Nashorn as a plugin framework.
> >
> > However, code like:
> >
> >    engine.eval(new BufferedReader(new FileReader("coffee-script.js")));
> >
> > easily takes 10-15 seconds. V8 uses a few milliseconds (when using jav8 as
> > scriptengine)
> >
> > In my opinion, Nashorn is so slow on startup it's useless (I have tons of
> > plugin scripts, which accumulates to 2-3 minutes of application startup
> > time due to nashorn - with v8 i'm subsecond!)
> >
> > What's going on? Anything I can do to fix this?
> >
> > Lang
> 
>