Statistics about CDS effectiveness

Tue Jun 11 05:54:22 UTC 2024

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-introduction.html#context-functionality-startup
[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 at 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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/leyden-dev/attachments/20240611/44b2d7cb/attachment.htm>