It was a typo when the original CLEARING_MASK was initially introduced:
// Mask to clear normal event bits. const jlong CLEARING_MASK = (1L >> (TOTAL_MIN_EVENT_TYPE_VAL - TOTAL_MIN_EVENT_TYPE_VAL)) - 1L; // Avoid cleaning extension event bits. jlong enabled_bits = CLEARING_MASK & env->env_event_enable()->_event_callback_enabled.get_bits(); ``` The first TOTAL_MIN_EVENT_TYPE_VAL has to be JVMTI_MIN_EVENT_TYPE_VAL as below: ` const jlong CLEARING_MASK = (1L >> (JVMTI_MIN_EVENT_TYPE_VAL - TOTAL_MIN_EVENT_TYPE_VAL)) - 1L;` Let me provide some background to understand how this mask is used. Normal JVMTI event types are numbered from 50 to 88. There are two constants: JVMTI_MIN_EVENT_TYPE_VAL = 50 JVMTI_MAX_EVENT_TYPE_VAL = 88 The extension event types are numbered from 47 to 49. There are also two constants: EXT_MIN_EVENT_TYPE_VAL = 47 EXT_MAX_EVENT_TYPE_VAL = 49 There are also two additional constants: TOTAL_MIN_EVENT_TYPE_VAL = 47 TOTAL_MAX_EVENT_TYPE_VAL = 88 The `enabled_bits` are shifted left by 47, so that the 0-bit in `enabled_bits` is for first extension event type. And the first normal JVMTI event type is numbered 3 in the `enabled_bits` bit mask. The `CLEARING_MASK` is used to clear only normal JVMTI event types but keep the extension event bits (0-2) unchanged. Testing: I'll run all JVMTI tests including nsk.jvmti tests and serviceability/jvmti tests including those added in Loom for virtual thread coverage. ------------- Commit messages: - 8286490: JvmtiEventControllerPrivate::set_event_callbacks CLEARING_MASK computation is incorrect Changes: https://git.openjdk.java.net/jdk/pull/8860/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=8860&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8286490 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/8860.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/8860/head:pull/8860 PR: https://git.openjdk.java.net/jdk/pull/8860
