Skip to content

Replace per-bit listener count fields with an AtomicIntegerArray#2664

Draft
vogella wants to merge 1 commit into
eclipse-platform:masterfrom
vogella:refactor-resource-listener-bit-counters
Draft

Replace per-bit listener count fields with an AtomicIntegerArray#2664
vogella wants to merge 1 commit into
eclipse-platform:masterfrom
vogella:refactor-resource-listener-bit-counters

Conversation

@vogella
Copy link
Copy Markdown
Contributor

@vogella vogella commented May 18, 2026

Collapses the six volatile count1..count32 fields and the four near-identical switch/if-bit helpers in ResourceChangeListenerList into a single AtomicIntegerArray indexed by Integer.numberOfTrailingZeros(mask). The bookkeeping is now linear in the number of set bits, future event types are a no-op to support, and hasListenerFor no longer silently drops anything outside the hard-coded 1..32 range. Behaviour and thread-safety guarantees are preserved.

Planned for 4.41

ResourceChangeListenerList tracked per-event-type listener counts in six
discrete volatile int fields (count1..count32), with adding(), removing(),
hasListenerFor(), and clear() each duplicating a hard-coded switch over the
same six bitmask values. Every new IResourceChangeEvent type required
adding a field and four matching cases, and any mask bit that no one
remembered to wire up was silently dropped by hasListenerFor.

Collapse the bookkeeping into a single AtomicIntegerArray indexed by
Integer.numberOfTrailingZeros(mask). adjust(mask, delta) walks the set bits
of the mask once, replacing the two near-identical adding/removing helpers.
hasListenerFor short-circuits non-single-bit and non-positive arguments,
matching the previous switch's default-false behavior, and otherwise reads
the counter for the single bit position.

AtomicIntegerArray preserves the per-element volatile read semantics that
hasListenerFor depends on outside the synchronized add/remove/clear paths.
Drops the unreachable "listeners != null" guard in toString since the
field is final and initialized at declaration, and inlines the
ListenerEntry.toString StringBuilder into a concatenation expression for
parity with the simplified outer toString.
@github-actions
Copy link
Copy Markdown
Contributor

Test Results

    54 files  ±0      54 suites  ±0   35m 20s ⏱️ - 1m 26s
 4 667 tests ±0   4 645 ✅ ±0   22 💤 ±0  0 ❌ ±0 
11 895 runs  ±0  11 742 ✅ ±0  153 💤 ±0  0 ❌ ±0 

Results for commit aa8786a. ± Comparison against base commit 4149373.

@iloveeclipse
Copy link
Copy Markdown
Member

The bookkeeping is now linear in the number of set bits, future event types are a no-op to support, and hasListenerFor no longer silently drops anything outside the hard-coded 1..32 range

These a valid points from AI point of view, but from human point of view:

  1. There are no planned changes on listeners, IResourceChangeEvent API is stable since ~ 18 years.
  2. Changed code is harder to understand for humans.

So while change "technically" itself is OK, it makes debugging / maintenance harder for humans.
"no go" from me.

@vogella
Copy link
Copy Markdown
Contributor Author

vogella commented May 18, 2026

I plan to add build events for individual projects and builder (requires events for projects), hence this change. This would allow clients to measure the build time of these builders on each project.

No problem if it is rejected, still possible to add new events just ugly to do so.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants