On Tue, 24 May 2022 20:45:09 GMT, Chris Plummer <cjplum...@openjdk.org> wrote:
>> 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. > > What would it take to write a test that fails due to this bug? @plummercj I've updated the serviceability/jvmti/vthreadVThreadTest to provide test coverage for this issue. The updated test is failed without this fix and is passed with it. ------------- PR: https://git.openjdk.java.net/jdk/pull/8860
