JEP: https://bugs.openjdk.java.net/browse/JDK-8203832

[Tobias Hartmann]

Hi Yumin,

This reminds me of a project we did for a student's bachelor thesis in 2015:
https://github.com/mohlerm/hotspot/blob/master/report/profile_caching_mohlerm.pdf

We also published a paper on that topic:
https://dl.acm.org/citation.cfm?id=3132210

Thanks for submitting the JEP, very interesting! Here are the things we've learned from the "cached
profiles" project, maybe you can correct this from your experience with JWarmup:
- Startup: We were seeing great improvements for some benchmarks but also large regressions for
others. Problems like the overhead of reading the profiles, overloading the compile queue and
increased compile time due to more optimizations affect the startup time.
- Peak performance: Using profile information from a previous run might cause significant
performance regressions in early stages of the execution. This is because a "late" profile is
usually also the one with the fewest optimistic assumptions. For example, the latest profile from a
previous run might have been updated right when the application was about to shut down. If this
triggered class loading or has other side effects, we might not be able to inline some methods or
perform other optimistic optimizations. Using this profile right from the beginning in a subsequent
run limits peak performance significantly.

Here are some questions more detailed questions:
- How is it implemented? Is it based on the replay compilation framework?
- How do you handle dynamically generated code (for example, lambda forms)?
- What information is stored/re-used and which profile is cached?
- Does it work for C1 and C2?
- How is the tiered compilation policy affected?
- When do we compile (if method is first used or are there still thresholds)?
- How do you avoid overloading the compile queue?
- Is re-profiling/re-compilation supported?
- What if a method is deoptimized? Is the cached profile update and re-used?

Best regards,
Tobias

On 29.05.2018 06:09, yumin qi wrote:
> Hi， Experts
> 
>   This is a newly filed JEP (JWarmup) for working on resolving java
> performance issue caused by both application load peaking up and JIT
> threads compiling java hot methods happen at same time.
> 
>   https://bugs.openjdk.java.net/browse/JDK-8203832
> 
>    For a large java application, the load comes in short period of time,
> like the 'Single Day' sale on Alibaba's e-commerce application, this
> massive load comes in and makes many java methods ready for JIT compilation
> to convert them into native methods. The compiler threads will kick in to
> do the complication work and take system resource from  mutator java
> threads which are busy on processing requests thus lead to peak time
> performance degradation.
> 
>    The JWarmup technique was proposed to avoid such issue by precompiling
> the hot methods at application startup and it has been successfully applied
> to Alibaba's e-commerce applications. We would like to contribute it to
> OpenJDK and wish it can help  java developers overcome the same issue.
> 
>    Please review and give your feedback.
> 
>   Thanks
>   Yumin
> 
>    (Alibaba Group Inc)
>