7127687: MethodType leaks memory due to interning

[John Rose]

Jim's and Remi's comments on the problem are correct.

In the current design, MH.type values must be interned.  Comments on this design decision are interesting and useful, but this is not new ground; we went over it during the JDK 7 engineering and spec. work.  It is likely we will revisit this decision at some point, but not today.

To risk stating the obvious: I am not asking at this point for a review of the use of interned method types.  I am asking for a review of a change to the mechanism *by which they are interned*.

— John

P.S. I will also point out that the "intern" design pattern, although very old in Java (String.intern), is poorly supported by the collections API.  I think a lot of the comments people have are based on the assumption, "surely there must be a way to do this without so much code copying".  One would hope so, but in this case one would be wrong.  What's needed is a Set with the following properties:

1. Assuming set.contains(x), a way to return a reference to the equal value x' already in the set.
2. Assuming !set.contains(x), a way to insert x.
3. Thread safety.
4. Weak references, so that unreferenced elements x' are quietly dropped.

1,2 would be covered by something like this hypothetical API:
  interface InterningSet<T> extends Set<T> {
    E intern(E x);  // ensures in set; returns x or pre-existing x'
    E find(E x);  // returns null if not in set, else pre-existing x'
  }

Every JVM has some mechanism like this for String.intern, somewhere.