Hi Went ahead and created https://github.com/apache/tomcat/pull/547 (if it helps)
Romain Manni-Bucau @rmannibucau <https://twitter.com/rmannibucau> | Blog <https://rmannibucau.metawerx.net/> | Old Blog <http://rmannibucau.wordpress.com> | Github <https://github.com/rmannibucau> | LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book <https://www.packtpub.com/application-development/java-ee-8-high-performance> Le lun. 22 août 2022 à 14:25, Romain Manni-Bucau <rmannibu...@gmail.com> a écrit : > +1 > > To answer the proxy reference: it affects other cases - loading classes > from a "database", proxies is just a well known case I used to illustrate > my point. By contract a classloader is not always an URLClassLoader which > is the assumption of the impl right now. Also CDS changes the perf there > too - a lot when enabled. > > Side note: graalvm integration is way easier without that check ;). > > Romain Manni-Bucau > @rmannibucau <https://twitter.com/rmannibucau> | Blog > <https://rmannibucau.metawerx.net/> | Old Blog > <http://rmannibucau.wordpress.com> | Github > <https://github.com/rmannibucau> | LinkedIn > <https://www.linkedin.com/in/rmannibucau> | Book > <https://www.packtpub.com/application-development/java-ee-8-high-performance> > > > Le lun. 22 août 2022 à 13:54, Mark Thomas <ma...@apache.org> a écrit : > >> On 22/08/2022 11:48, Mark Thomas wrote: >> > On 22/08/2022 10:20, Romain Manni-Bucau wrote: >> >> <snip/> >> >> >> So overall I wonder if this check can be dropped now we have concurrent >> >> classloaders and cache almost everywhere. If not, should the missed >> items >> >> be cached in some (webapp) classloader to help to exit faster? >> > >> > We need to test with various JDKs but if the results are comparable to >> > those for Java 11, I'd have no objection to simplifying the code. >> >> I've just run the performance test with Java 7, Java 8 and Java 11 with >> 8.5.x and in all three cases, the average time to run the test was less >> without the performance fix than with it. >> >> Given these, results, I think we remove this performance hack for all >> current versions. >> >> Objections? >> >> Mark >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org >> For additional commands, e-mail: dev-h...@tomcat.apache.org >> >>
