jengebr commented on PR #770:
URL: https://github.com/apache/tomcat/pull/770#issuecomment-2450799286
Thank you so much! :)
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
markt-asf commented on PR #770:
URL: https://github.com/apache/tomcat/pull/770#issuecomment-2450776553
Those were the only changes required. Fix applied to main, 11.0.1, 10.1.x
and 9.0.x.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on
markt-asf closed pull request #770: Reducing memory usage while evaluating
reflective EL expressions
URL: https://github.com/apache/tomcat/pull/770
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to th
markt-asf commented on PR #770:
URL: https://github.com/apache/tomcat/pull/770#issuecomment-2450753071
I'm planning on applying this manually to main and then back-porting. So far
I've made the following changes:
- refactored the inner test classes to align with the rest of the package
jengebr commented on PR #770:
URL: https://github.com/apache/tomcat/pull/770#issuecomment-2448361853
Changes are committed as discussed, ready for re-review. Specifically:
1. Cache is removed, fast-path is added for zero-arg cases
1. Unit tests are added for:
- Zero-args method look
markt-asf commented on PR #770:
URL: https://github.com/apache/tomcat/pull/770#issuecomment-2448199694
Actually, it does belong to us. It isn't part of the public API. We are free
to change it how we wish. If you compare our version to the equivalent code in
the EL API JAR from Jakarta EE t
ChristopherSchultz commented on PR #770:
URL: https://github.com/apache/tomcat/pull/770#issuecomment-2448176904
> @ChristopherSchultz what prevents changes to `javax.el.Util`?
That class doesn't "belong" to us. Depending upon how it changes, we might
fail the TCK. It's just better to
jengebr commented on PR #770:
URL: https://github.com/apache/tomcat/pull/770#issuecomment-2448111787
This complexity led me to try a fallback plan, which can be faster: if the
method has zero parameters, retrieve the Method by name. This works because
there is no confusion about parameter
markt-asf commented on PR #770:
URL: https://github.com/apache/tomcat/pull/770#issuecomment-2448093530
I think the changes will have to go into `Util`. Something like a map of
caches, keyed by class loader with appropriate use of weak references to avoid
class loader leaks.
--
This is an
jengebr commented on PR #770:
URL: https://github.com/apache/tomcat/pull/770#issuecomment-2448015687
Thanks, I get your points about caching scope and cleanup.
@ChristopherSchultz what prevents changes to `javax.el.Util`?
--
This is an automated message from the Apache Git Service.
ChristopherSchultz commented on PR #770:
URL: https://github.com/apache/tomcat/pull/770#issuecomment-2447969657
> I'd also like to see the key remove from the cache when the value expires.
+1
So I think your technique @jengebr is good, but the cache just needs to be
pulled-up i
markt-asf commented on PR #770:
URL: https://github.com/apache/tomcat/pull/770#issuecomment-2447798338
Any caching approach needs to consider the case of two classes in different
web applications with the same name but different structures. Essentially,
caching needs to be per class loader.
ChristopherSchultz commented on PR #770:
URL: https://github.com/apache/tomcat/pull/770#issuecomment-2429756034
I was also surprised recently to discover that the JVM does not cache
results of `Class.getMethods` and similar calls. Maybe it's returning a clone
each time, but either way it ta
jengebr opened a new pull request, #770:
URL: https://github.com/apache/tomcat/pull/770
This change fixes https://bz.apache.org/bugzilla/show_bug.cgi?id=69381 by
caching the JVM-provided `Method[]`. The OpenJDK compiler creates duplicate
`Method` objects on every call to `Class.getMethods(
14 matches
Mail list logo
