I'm reluctant to try building jdk9 on my Windows machine :) When will an early access build with class caching reach https://jdk9.java.net/download/ ?
Thanks! On Wed, Jul 2, 2014 at 2:01 PM, Marcus Lagergren < [email protected]> wrote: > > 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 < > [email protected]> 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 <[email protected]> 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 >> >> > >
