+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 > >
