Thanks for the PR, and +1 to @reiabreu's two points — they're both on the mark. A few things to add on top.

On the comparator refactor (@reiabreu's line 334 suggestion): it's correct and worth doing — I checked the Cluster internals and getAvailablePorts() = getAssignablePorts() − usedPorts (Cluster.java:411-418), so a host's available slots are always a subset of its assignable slots. That means counting free slots among each host's own assignable list is exactly equivalent to the current "bucket getAvailableSlots() by host" approach — safe to switch, and it lifts the map lookup out of the comparator. One gotcha: the suggested snippet uses cluster::isSlotAvailable, which doesn't exist — the method is cluster.isSlotOccupied(WorkerSlot), so the predicate needs to be slot -> !cluster.isSlotOccupied(slot) (or just keep deriving the count from getAvailableSlots() and pass it into the constructor).

On unit tests (@reiabreu's earlier ask): I'd treat this as the one blocker. There's currently no focused IsolationScheduler test anywhere in the tree, so this selection path is entirely uncovered and the value of the change is unverifiable. A small test pinning both new keys would do it:

• two hosts, equal assignable slots, different free-slot counts → assert the host with more free slots (fewer evictions) is selected first;
• two hosts equal on both → assert the lexicographic hostname tiebreak.

The tertiary hostname sort is a nice fix in its own right — the comparator's input came from HashMap.entrySet(), so equal-ranked hosts were previously ordered non-deterministically.

LGTM on the logic; I'd just want the unit test before merge. 👍