Summary
-------

Reduce LambdaForm creation and use caching to improve the performance of
dynamic languages.


Goals
-----

Considerably reduce memory footprint while preserving current
peak-performance metrics.


Motivation
----------

Many method-handle transforms (e.g., `MethodHandles::filterReturnValue`)
create many new LambdaForm instances for each transformed method handle.
This induces excessive memory usage in applications that make heavy use
of method handles.


Description
-----------

The current method-handle implementation instantiates LambdaForms too
aggressively.  The proposed approach is two-fold: Share LambdaForm
instances and their bytecodes for similar transformations, and cache
lambda forms for different combinators on a per-basic-type basis (see
`MethodTypeForm.lambdaForms`).


Testing
-------

Existing tests give good coverage of functionality.  Some focused tests
(i.e., white-box tests verifying actual sharing in different cases) are
also desirable.

Existing tests:

  - `jdk/test/java/{lang/invoke,util/stream}`
  - mlvm tests
  - Nashorn unit tests
  - ECMA test262
  - Octane benchmarks

Testing modes: 

  - out-of-box: no flags
  - assertions: `-ea -esa`
  - interpreted vs. compiled LFs:
    `-Djava.lang.invoke.MethodHandle.COMPILE_THRESHOLD={0,30}`.


Risks and Assumptions
---------------------

The implementation shouldn't cause any regression in peak performance.
Experiments show, however, that preserving peak performance may prevent
maximal sharing in some situations (e.g., `MethodHandles.guardWithTest`,
where profile pollution due to sharing distorts inlining decisions of JIT
compiler).  We'll need to find a suitable balance between footprint
reduction and peak performance during development.


Impact
------

The changes are concentrated in Java portion of the method-handle
implementation (i.e., the `java.lang.invoke` and `sun.invoke` packages).
There is no impact upon those who don't use method handles.  No new APIs
will be added and no existing APIs will be changed.