performance - Why is Java 8 slower to warm up -

in our efforts move java 6 (u39) java 8 (u51) facing issue of longer warm times java 8 compared 6.

we noticed both performance test run java program , initial requests when starting tomcat 7 (u35) java 8.

we running on linux redhat 64 bit system.

i sorry not have isolated test case.

regarding performance test program found java 6 came close steady state performance of around 215 milliseconds in 10 iterations whereas java 8 taking 800 milliseconds after 10 iterations , took 70+ iterations reach 215 ms.

when ran jmeter tests @ concurrency of 10 on our tomcat webapp (with spring 2.5, jackson, xerces xml parser, jedis etc.) after re-starting java 6 took less minute give steady state performance whereas java 8 took around 5-6 minutes , slower several orders of magnitude till then.

turning off tiered compilation using -xx:-tieredcompilation vm hotspot option in java 8 fixed warm issue performance test program no change in steady state performance. surprising since tiered compilation supposed give faster warm up.

however turning off tiered compilation did not give similar improvement in warm time tomcat server.

i welcome suggestion fix issue since deploying new build in live environment can become hassle long warm time.

thanks, suresh

this surprising since tiered compilation supposed give faster warm up.

you're confusing time-to-peak-performance , time-to-initialized/responsive-application.

+tiered

• interpreter (tier 0) -> c1 (tier 1-3) -> c2 (tier 4)
• heavy c2 work gets delayed later point of time
• more time spent in c1-compiled code means type profiles after application startup might cleaner, allowing better optimization , fewer decompilations in c2
• application can serve first request sooner / reaches user interactivity / shortlived java executions finish sooner

-tiered

• interpreter -> c2
• hot code may reach peak performance sooner
• initialization , merely-warm code may take longer
• less time spent profiling may under circumstances lead suboptimal code

another thing play number of compiler threads (cicompilercount). performance tradeoffs complicated, benchmarking various settings can helpful.