[prev in list] [next in list] [prev in thread] [next in thread] 

List:       openjdk-serviceability-dev
Subject:    Re: How can Java developers best understand their impact on the start-up of the JVM?
From:       David Holmes <david.holmes () oracle ! com>
Date:       2022-05-26 2:10:06
Message-ID: be827a1a-4559-6960-34e3-db01bbf622ab () oracle ! com
[Download RAW message or body]

cc'ing hotspot-jfr-dev

On 26/05/2022 9:45 am, Mat Carter wrote:
> The Microsoft Java Engineering Group (JEG) have been looking at how Java developers \
> can best understand the impact of their decisions on start-up time. Specifically, \
> how developers can identify and mitigate the dominant activities that occur during \
> start-up, through to their app / service reaching a steady state (warmed up). 
> Upon investigation into the available tooling (i.e., jstat, jcmd, jmc, VisualVM, \
> MXBeans), it seems that Performance Counters (PCs) and JDK Flight Recorder events \
> (JFREs) are the main source of the available startup metrics that get surfaced. 
> Whilst the tooling does provide insight to specific areas (GC, JIT Compilation \
> etc.), there does not seem to be one view to help a developer identify the dominant \
> activities that are impacting start-up. 
> Q: Has the above been discussed before and are there any existing plans to address \
> the outcomes that I might have missed? 
> Looking at the specific PCs and JFREs there are a few "missing" metrics, for \
> example a timestamp at the very beginning entry point of the JVM. Also, it appears \
> that the JFREs represent a subset of the PCs - does this indicate that either some \
> PCs should be removed (or only enabled for JVM development) or that there remain \
> JFREs to be added? 
> Q: Is there a current position on whether PCs and JFREs will continue to co-exist \
> (the former supporting JMX MXBeans, et al.), or is there a plan to phase out PCs in \
> favor of JFREs? 
> Q: Assuming PCs should continue to exist, do folks see the value in documenting \
> them and making them readily accessible to the running application? Especially in \
> the deployment scenario where running a second application or tool (to sample the \
> PCs remotely) is not feasible. FYI - during our initial investigations we wrote \
> some scripts to find all possible PCs. We did this because jcmd only lists \
> instantiated PCs and the PC names are procedurally generated, making them \
> non-trivial to search for. 
> Q: Do folks see value in documenting the JFREs, especially since the application \
> can access the JFR Event stream? (There is non-official documentation available \
> [1]) 
> Q: While Project Leyden concerns itself primarily with improving start-up times, \
> are there any other known activities targeting profiling of Java applications (esp. \
> start-up)? 
> Answers and discussion of the above is most welcome so that our group moves forward \
> in helping our customers, whilst staying aligned with and contributing to the \
> OpenJDK community! 
> Thanks in advance
> Mat Carter
> 
> [1] https://bestsolution-at.github.io/jfr-doc/index.html


[prev in list] [next in list] [prev in thread] [next in thread] 

Configure | About | News | Add a list | Sponsored by KoreLogic