From 1655362684 at qq.com Mon May 18 03:40:05 2020 From: 1655362684 at qq.com (=?gb18030?B?yO7Wxw==?=) Date: Mon, 18 May 2020 11:40:05 +0800 Subject: Questions about nashorn Message-ID: Hello, I have some questions about using nashorn in the project The first question: what is the usage scenario of nashorn.option.class.cache.size, and what benefits can be brought by modifying (increasing or decreasing) this value The second question: why is it very slow to execute the evel function and invokeFunction function for the first time. I understand that the first time evel takes time is mainly to compile the script, but why the invokeFunction function is also slow for the first and second time, and tends to be stable for the third time and later, and the performance reaches the best From HANNES.WALLNOEFER at ORACLE.COM Tue May 19 13:12:02 2020 From: HANNES.WALLNOEFER at ORACLE.COM (Hannes Wallnoefer) Date: Tue, 19 May 2020 15:12:02 +0200 Subject: Questions about nashorn In-Reply-To: References: Message-ID: Hello, Answers inline below. > Am 18.05.2020 um 05:40 schrieb ?? <1655362684 at qq.com>: > > Hello, I have some questions about using nashorn in the project > > The first question: what is the usage scenario of nashorn.option.class.cache.size, and what benefits can be brought by modifying (increasing or decreasing) this value > Nashorn compiles JS scripts to Java classes. The class cache size property defines the number of compiled script classes that are cached for reuse. So if you compile and evaluate a lot of scripts and use some scripts repeatedly, tweaking this option may improve performance by avoiding recompilation of scripts. > > The second question: why is it very slow to execute the evel function and invokeFunction function for the first time. I understand that the first time evel takes time is mainly to compile the script, but why the invokeFunction function is also slow for the first and second time, and tends to be stable for the third time and later, and the performance reaches the best The first run of Java code on a VM with adaptive optimizations is always slow. In the case of Nashorn, this affects the parser and compiler, the runtime libraries and the compiled script itself, so the effect is quite noticeable. Hannes