RFR: 8324241: Always record evol_method deps to avoid excessive method flushing [v5]

[leo liang]

On Thu, 12 Sep 2024 15:44:21 GMT, Volker Simonis <simonis at openjdk.org> wrote:

>> Hi there, we are seeing this issue when we run JFR on our services under load, we see a large spike of CPU after JFR is triggered, which cause 500 errors in our service. We are currently using corretto-17 in our service.
>> 
>> Wondering this fix get back ported to JDK 17? As I can't find this change mentioned in [JDK update](https://wiki.openjdk.org/display/JDKUpdates/Archived+Releases) or in [jdk17u tag compare](https://github.com/openjdk/jdk17u/compare/jdk-17.0.9+9...jdk-17.0.13+1)
>> 
>> Also, wondering if there is a walk around for this issue if the PR is not back ported to Java 17. `XX:+EnableDynamicAgentLoading` seems to only supported in Java 21, so that wouldn't help for now
>
>> Hi there, we are seeing this issue when we run JFR on our services under load, we see a large spike of CPU after JFR is triggered, which cause 500 errors in our service. We are currently using corretto-17 in our service.
>> 
>> Wondering this fix get back ported to JDK 17? As I can't find this change mentioned in [JDK update](https://wiki.openjdk.org/display/JDKUpdates/Archived+Releases) or in [jdk17u tag compare](https://github.com/openjdk/jdk17u/compare/jdk-17.0.9+9...jdk-17.0.13+1)
>> 
>> Also, wondering if there is a walk around for this issue if the PR is not back ported to Java 17. `XX:+EnableDynamicAgentLoading` seems to only supported in Java 21, so that wouldn't help for now
> 
> @leomao10, I'm not sure if this change will ever be downported to older releases like JDK 21 or even JDK 17. I personally consider it low risk, but there have been reports of performance regressions in some cases (e.g. [JDK-8336805](https://bugs.openjdk.org/browse/JDK-8336805)). I couldn't reproduce them, but I can image that they will make the maintainers of LTS releases even more cautious.
> 
> The easiest way to workaround this issue in JDK 17 would be to set the `can_redefine_classes`, `can_retransform_classes` or `can_generate_breakpoint_events` JVMTI capabilities at startup or early in the lifetime of the JVM. There are several ways how you could do this.
> - trigger JFR right after startup. This will still invalidate all the JIT compiled methods but if you do this early enough there won'T be many of them. After you've triggered JFR for the first time, the corresponding JVMTI capabilities will be set and all dependencies will be recorded automatically so any subsequent JFR invocation won't suffer from a performance degradation any more.
> - attach any other JVMTI agent like for example [async profiler](https://github.com/async-profiler/async-profiler) which requests the corresponding JVMTI capabilities at startup.
> - write your own, trivial JVMTI agent which merely requests the corresponding JVMTI capabilities and attach it at startup with `agentpath:jvmtiAgent.so`. The agent can be as simple as:
> 
> /*
> 
> g++ -fPIC -shared -I $JAVA_HOME/include/ -I $JAVA_HOME/inlude/linux -o jvmtiAgent.so jvmtiAgent.cpp
>  */
> 
> #include <jvmti.h>
> #include <stdio.h>
> #include <string.h>
> 
> extern "C"
> JNIEXPORT jint JNICALL Agent_OnLoad(JavaVM* jvm, char* options, void* reserved) {
>   jvmtiEnv* jvmti = NULL;
>   jvmtiCapabilities capa;
>   jvmtiError error;
> 
>   jint result = jvm->GetEnv((void**) &jvmti, JVMTI_VERSI...

That is awesome, thanks for the response and workarounds @simonis  ❤️

-------------

PR Comment: https://git.openjdk.org/jdk/pull/17509#issuecomment-2352169138