On 24/08/2022 14:40, Romain Manni-Bucau wrote:
Hi
Went ahead and created https://github.com/apache/tomcat/pull/547 (if it
helps)
Thanks. There weren't any objections so I'll merge that PR shortly.
Mark
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
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
