Extremely slow startup performance

[Sia Lang]

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 <
marcus.lagergren at oracle.com> 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 <
> 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
>>
>>
>
>