`ImmutableCollections$SetN.probe()` slowdown suggests hot inner loop with Set operations

[laeubi]

During analysis of two heapdumps shared here the following issue was discovered as a hotspot that can benefit from optimization:

Performance Data

Metric	WITH transitive	WITHOUT transitive	Ratio
SetN.probe() self time (µs)	23,483,483	5,370,299	4.4×

Description

ImmutableCollections$SetN.probe() is the internal method used by Set.of(...) immutable sets for contains() checks. The 4.4× slowdown (23.5 seconds!) indicates that some hot loop is checking membership in an immutable set far more frequently with transitive dependencies.

This likely comes from module system-related lookups (checking if a module name is in a set of known modules, or if a package is in a set of accessible packages). The Set.of() probe uses linear probing and can degrade with hash collisions.

Suggested Fix

1. Identify the caller via a more detailed profile with call tree attribution. The callers are likely in ModuleBinding, ModulePathEntry, or module access checking code.
2. If the set is large, consider using HashSet instead of Set.of() — ImmutableCollections.SetN uses a flat array with linear probing, which degrades for larger sets (> ~30 elements). HashSet uses chaining and performs better at scale.
3. Cache the result of frequent contains() checks if the same elements are looked up repeatedly.