Statistics about CDS effectiveness

Ioi Lam ioi.lam at oracle.com
Wed Jan 24 13:23:16 UTC 2024


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. 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/leyden-dev/attachments/20240124/e1a056eb/attachment.htm>


More information about the leyden-dev mailing list