And people replied that they don't have this issue. Is this an issue with my platform or is this an issue with the memory usage of subsets?
It would be great if you could show me a way to get around this issue.

range returns a chunked sequence, and when map processes a chunked sequence it preserves the chunks. Chunks are little Java arrays of Object references, pointing at the results, and none of them will be GCed until the entire chunk is finished being processed.

It might be that a few other calls to unchunk wrapped around range calls might be useful in the math.combinatorics library, but certainly not all of them.

These loop auto-boxing warnings are because integer literals are now read in as primitive longs (since 1.6?), but these loops want boxed longs.

The simplest fix, I think, would be to replace the literals in the loop args with boxed longs. So, for example, 1 becomes (Long. 1). I believe that this is what the compiler does automatically when it sees that recur isn't passing in a primitive long (thus the warning that it is auto-boxing the loop arg), so I don't think it would have any impact on performance (this isn't actually a warning that it needs to do reflection at runtime), but it would make the warning disappear.

Breaking the loop out into a separate function strikes me as a heavy-handed solution (it makes the warning disappear because Clojure boxes numbers on function calls unless otherwise annotated, but there's really no need to break it into a separate function).

Came upon this as I was trying to improve performance. The implementation of sorted-numbers? (only used by permutations) is:
(defn- sorted-numbers?
"Returns true iff s is a sequence of numbers in non-decreasing order"[s]
(and (every? number? s)
(every? (partial apply <=) (partition 2 1 s))))

<= and similar operators are variadic, so partitioning into pairs is unneeded.
(apply <= s) is a lot faster, but breaks for empty sequences, so an additional check is needed.

The implementation can be changed to:

(and (every? number? s)
(or (empty? s) (apply <= s)))

I benched this to be 10 to 15 times faster. A regression test with test.check was done to verify that the behaviour was not changed under any input.
A patch is also included.

Thanks for the submission. I don't know whether Mark would be interested in taking the test.check regression test you developed, too, but if you would be willing to share it as a patch, it might be considered for inclusion as well.

Hm, I don't know how I could include the regression test as a patch. Because:
1) The current project does not use external libraries or Leiningen (yet). How do I add dependencies when not using Leiningen?
2) I tested the old implementation vs the new one with generated inputs. If the old implementation is gone, there's no test to add...

Since this function is only called once at the beginning of the permutations process, on a sequence that is usually 10 or fewer items, I can't imagine this improvement will have any meaningful impact on the overall running time of the permutations algorithm. Nevertheless, it's an improvement, so I've gone ahead and added it.

Main downside is increasing the minimum Clojure version from 1.2 to 1.7 for CLJC support. Alex Miller also indicated that the Clojure CI system was not ready for CLJC files yet, but that it would be nice to have the ticket and patch ready.