The commit from JDK-8314745 contains

jlong JNICALL jfr_register_stack_filter(JNIEnv* env, jobject classes, jobject methods);
jlong JNICALL jfr_unregister_stack_filter(JNIEnv* env, jlong start_filter_id);

in jfrJniMethod.hpp, but the definitions have different signatures:

JVM_ENTRY_NO_ENV(jlong, jfr_register_stack_filter(JNIEnv* env, jclass jvm, jobjectArray classes, jobjectArray methods))
  return JfrStackFilterRegistry::add(classes, methods, thread);
JVM_END

JVM_ENTRY_NO_ENV(void, jfr_unregister_stack_filter(JNIEnv* env, jclass jvm, jlong id))
  JfrStackFilterRegistry::remove(id);
JVM_END

this doesn't seem to impact regular builds but leads to linkage failures on 32-bit Windows where JNICALL has meaning and seems to perform more checking/validation..

[2024-04-10T22:32:04,146Z] jfrJniMethodRegistration.obj : error LNK2019: unresolved external symbol _jfr_register_stack_filter@12 referenced in function "public: __thiscall JfrJniMethodRegistration::JfrJniMethodRegistration(struct JNIEnv_ *)" (??0JfrJniMethodRegistration@@QAE@PAUJNIEnv_@@@Z)
[2024-04-10T22:32:04,146Z] Hint on symbols that are defined and could potentially match:
[2024-04-10T22:32:04,146Z] _jfr_register_stack_filter@16
[2024-04-10T22:32:04,146Z] jfrJniMethodRegistration.obj : error LNK2019: unresolved external symbol _jfr_unregister_stack_filter@12 referenced in function "public: __thiscall JfrJniMethodRegistration::JfrJniMethodRegistration(struct JNIEnv_ *)" (??0JfrJniMethodRegistration@@QAE@PAUJNIEnv_@@@Z)
[2024-04-10T22:32:04,146Z] Hint on symbols that are defined and could potentially match:
[2024-04-10T22:32:04,146Z] _jfr_unregister_stack_filter@16