Hi Ioi, Sorry for dropping the ball on this. I don't have much experience with JFR. We use it to track what happens when the ApplicationContext processes user configuration and compose the beans to manage[1] as there's been some misunderstanding from the community when the time was spent. Hopefully that explains why I suggested that route. We're back from the Spring I/O conference where CDS was showcased in the keynote[2][3] as well as in several breakout sessions. We got more feedback from the community about the need for tooling to validate the training run was indeed effective and how it could improve if necessary. I thought about having some dedicated MBeans in the JVM's MBeanServer as well. On our end, we can see significant differences based on how "soon" we cut the training run phase. For instance, if we're ok to pay the cost of having a database connection during the training run (to validate/migrate the schema) we gain quite a bit in startup time compared to just disabling that single feature. I am happy to review and/or work with you to define the requirements if that's something the team would like to tackle. Cheers, S. [1] https://docs.spring.io/spring-framework/reference/core/beans/context-introdu... [2] https://www.youtube.com/watch?v=XUz4LKZx83g&t=711s [3] https://www.youtube.com/watch?v=XUz4LKZx83g&t=1159s On Wed, Jan 24, 2024 at 2:24 PM Ioi Lam <ioi.lam@oracle.com> wrote:

Hi Stephane,

I think your tool is quite useful and I like the format (cut-and-pasted below) that it reports the statistics. It can be used to diagnose configuration problems so that the application can use CDS effectively.

I also use the -Xlog:class+load output a lot, but I usually just use ad-hoc scripts.

For Leyden, I think we should think about improved logging and diagnostics for other artifacts as well (heap objects, AOT methods, etc). Some sort of central place (like JFR) for accessing such information would be useful. Do you have suggestions for how to integrate with JFR?

Thanks

- Ioi

-------------------------------------------------------------------------- Class Loading Report: 15909 classes and JDK proxies loaded 13140 (82,59%) from cache 2769 (17,41%) from classpath

Categories: Lambdas 1736 (10,91%): 11,23% from cache Proxies 175 ( 1,10%): 56,57% from cache Classes 14000 (88,00%): 91,76% from cache

Top 10 locations from classpath: 759 BOOT-INF/lib/byte-buddy-1.14.9.jar 347 __JVM_LookupDefineClass__ 75 __dynamic_proxy__ 69 org.springframework.boot.autoconfigure.web.embedded.TomcatWebServerFactoryCustomizer 39 31 org.springframework.boot.autoconfigure.web.servlet.ServletWebServerFactoryCustomizer 19 org.springframework.data.mapping.model.Property 16 org.springframework.core.io.support.SpringFactoriesLoader 16 org.springframework.data.mapping.model.AnnotationBasedPersistentProperty 16 org.springframework.boot.autoconfigure.web.WebProperties

Top 10 packages: 5078 org.springframework (77,37% from cache) 3776 org.hibernate (92,77% from cache) 847 java.lang (60,45% from cache) 810 net.bytebuddy (4,94% from cache) 737 java.util (98,78% from cache) 575 org.h2 (98,09% from cache) 523 com.fasterxml (95,98% from cache) 323 org.aspectj (100,00% from cache) 322 jdk.internal (99,07% from cache) 310 org.apache (97,74% from cache) --------------------------------------------------------------------------

On 1/23/24 00:39, Stephane Nicoll wrote:

Hey,

I hope this mailing list is the right place for this. I am working with Sébastien Deleuze on the Spring team and we've been focusing quite a bit on CDS lately and how it can be easily leveraged by our user base.

One thing we quickly found out was that the cache can be more or less effective depending on the way you start the app (classloaders, non deterministic list of jar files, etc). Initially, we were testing the startup time and comparing when CDS wasn't enabled.

I think there must be a better way and, for the lack of finding one, I've developed a (very) pragmatic approach of parsing the JVM logs and producing a report[1]. The tool has improved a bit for our own use case, creating the cache and providing a report of the warnings that were issued (to spot packages that couldn't be managed and why).

Parsing the logs is good enough for our little testing there but we were wondering if there was an appetite (or need) to productize this. We were thinking that JFR events could be an option.

Thanks, S.

[1] https://github.com/snicoll/cds-log-parser

This electronic communication and the information and any files transmitted with it, or attached to it, are confidential and are intended solely for the use of the individual or entity to whom it is addressed and may contain information that is confidential, legally privileged, protected by privacy laws, or otherwise restricted from disclosure to anyone else. If you are not the intended recipient or the person responsible for delivering the e-mail to the intended recipient, you are hereby notified that any use, copying, distributing, dissemination, forwarding, printing, or copying of this e-mail is strictly prohibited. If you received this e-mail in error, please return the e-mail to the sender, delete it from your computer, and destroy any printed copy of it.

-- This electronic communication and the information and any files transmitted with it, or attached to it, are confidential and are intended solely for the use of the individual or entity to whom it is addressed and may contain information that is confidential, legally privileged, protected by privacy laws, or otherwise restricted from disclosure to anyone else. If you are not the intended recipient or the person responsible for delivering the e-mail to the intended recipient, you are hereby notified that any use, copying, distributing, dissemination, forwarding, printing, or copying of this e-mail is strictly prohibited. If you received this e-mail in error, please return the e-mail to the sender, delete it from your computer, and destroy any printed copy of it.