The logic which creates and tracks BMH species is complex and error-prone.
It should be refactored into a smaller "specializer" engine which has no direct coupling to BMH, plus a smaller BMH-specific subclass that embodies the particulars of BMH logic.

The current combined logic is almost impossible to analyze, and will be difficult to enhance in the future.  Future enhancements include support for value types and additional applications of specialization.  One such application is sharable lambda implementations instead of per-site bespoke inner classes.  The current specialization mechanism is too BMH-specific to support such experiments.  Another specialization application is an argument-list API.  Value types will strain the present BMH framework past its breaking point (since each value type is potentially a distinct "LambdaForm.BasicType").  Other specialization tasks may include generating families of vector types (for the Panama Vector API) or for generating families of foreign types such as C pointers (again, Panama).

A prototype refactoring has been completed and seems promising.  For a toy example of non=BMH specialization, see the regression test:

http://cr.openjdk.java.net/~jrose/jdk/8184777/webrev.0/raw_files/new/test/java/lang/invoke/java.base/java/lang/invoke/ClassSpecializerHelper.java