Fix race condition in ImageHandleManager with ConcurrentHashMap

[Copilot]

Multiple threads concurrently accessing ImageHandleManager.getOrCreate() for the same zoom level could create duplicate handles, causing resource leaks and wasted CPU/memory. The non-thread-safe HashMap allowed this race:

// Thread A: get(150) → null, creates H1, put(150, H1)
// Thread B: get(150) → null, creates H2, put(150, H2)  // H1 leaked

Changes

ImageHandleManager (Image.java)

• HashMap → ConcurrentHashMap for thread-safe handle storage
• getOrCreate(): manual check-create-put → atomic computeIfAbsent()
• Removes redundant remove() call in destroyHandles()

ImageData caching

• HashMap → ConcurrentHashMap in ImageFromImageDataProviderWrapper and BaseImageProviderWrapper
• Already used computeIfAbsent(), now properly thread-safe

Implementation

// Before: 10+ lines, race-prone
DestroyableImageHandle imageHandle = (DestroyableImageHandle) get(zoom);
if (imageHandle != null) return imageHandle;
imageHandle = creator.get();
zoomLevelToImageHandle.put(zoom, imageHandle);
return imageHandle;

// After: atomic, 1 line
return zoomLevelToImageHandle.computeIfAbsent(zoom, k -> creator.get());

Testing

Snippet_ImageHandleRaceCondition.java: Demonstrates race condition with 20 threads × 100 iterations, tracks duplicate creation

test_ConcurrentImageHandleAccess(): JUnit test verifying exactly 1 handle created per zoom under concurrent access (10 threads × 50 iterations)

Rationale

ConcurrentHashMap chosen over double-checked locking for simplicity, correctness, and lock-free read performance. A unified caching structure was considered but deferred as it requires architectural refactoring beyond immediate thread-safety needs.

Warning

Firewall rules blocked me from connecting to one or more addresses (expand for details)

I tried to connect to the following addresses, but was blocked by firewall rules:

• www.eclipse.org
  • Triggering command: /opt/hostedtoolcache/Java_Temurin-Hotspot_jdk/21.0.9-10/x64/bin/java /opt/hostedtoolcache/Java_Temurin-Hotspot_jdk/21.0.9-10/x64/bin/java --enable-native-access=ALL-UNNAMED -classpath /opt/hostedtoolcache/maven/3.9.12/x64/boot/plexus-classworlds-2.9.0.jar -Dclassworlds.conf=/opt/hostedtoolcache/maven/3.9.12/x64/bin/m2.conf -Dmaven.home=/opt/hostedtoolcache/maven/3.9.12/x64 -Dlibrary.jansi.path=/opt/hostedtoolcache/maven/3.9.12/x64/lib/jansi-native -Dmaven.multiModuleProjectDirectory=/home/REDACTED/work/eclipse.platform.swt/eclipse.platform.swt org.codehaus.plexus.classworlds.launcher.Launcher clean compile -DskipTests -pl bundles/org.eclipse.swt -am (dns block)

If you need me to access, download, or install something from one of these locations, you can either:

• Configure Actions setup steps to set up my environment, which run before the firewall is enabled
• Add the appropriate URLs or hosts to the custom allowlist in this repository's Copilot coding agent settings (admins only)

Original prompt

The comment here eclipse-platform#2905 (comment) describes a possible scenario for a race condition.

I would need a testcase tha replicates the described scenario (e.g. with modify the code with some barriers we can use in a snippet). Also there needs to be an analysisy if the PR actually fixes the problem and double-checked locking is a good aproach or if it wont work with a ConcurrentMap maybe better. We should also consider different aproach where instead of the two maps we just merge both maps into using a special datastructure that can handle both cases. This seems a much better way forward to me.

---

💬 We'd love your input! Share your thoughts on Copilot coding agent in our 2 minute survey.