`MapSetMultiMap` performance degradation when backed by special sets

[jjppp]

📝 Overall Description

A MapSetMultiMap<K, V> can be backed by different user-defined sets to offer functionality similar to but cleaner than a Map<K, Set<V>>, which is quite nice.

However, the Set<V> get(K key) method of the class MapSetMultiMap will return a set of type UnmodifiableSet<V>, instead of using the set generated by the setFactory.

Tai-e/src/main/java/pascal/taie/util/collection/MapSetMultiMap.java

Lines 76 to 81 in e3eadc9

	public Set<V> get(@Nonnull K key) {
	Objects.requireNonNull(key, NULL_KEY);
	Set<V> values = map.get(key);
	return values == null ? Set.of() :
	Collections.unmodifiableSet(values);
	}

For cases when setFactory returns IndexerBitSets and operations like addAll are performed, this implementation will cause severe performance degradation as operations like addAll are slow when the type of the two sets are different.

Tai-e/src/main/java/pascal/taie/util/collection/GenericBitSet.java

Lines 100 to 107 in 89a4ea0

	public boolean addAll(@Nonnull Collection<? extends E> c) {
	if (c instanceof GenericBitSet s) {
	checkContext(s);
	return bitSet.or(s.bitSet);
	} else {
	return super.addAll(c);
	}
	}

🎯 Expected Behavior

return a set of the same type of the sets generated by setFactory

🐛 Current Behavior

Collections.unmodifiableSet() is used

🔄 Reproducible Example

No response

⚙️ Tai-e Arguments

🔍 Click here to see Tai-e Options

{{The content of 'output/options.yml' file}}

🔍 Click here to see Tai-e Analysis Plan

{{The content of 'output/tai-e-plan.yml' file}}

📜 Tai-e Log

🔍 Click here to see Tai-e Log

{{The content of 'output/tai-e.log' file}}

ℹ️ Additional Information

No response

[jjppp]

A note is added in bb9a8f8 to alert the developers