DRAFT DRAFT DRAFT

> I want to refactor BSM invocation to push more up into the libraries,
and make the remaining JVM-linked parts be less resolving and
more symbolic.  The basic idea here is a *single* uber-BSM that is
defined (as a static up-call API) in the JVMS and implemented
outside of the JVMS.  It will pass just enough raw, unresolved
information to allow the library to do what it needs to do to
implement current (indy/condy) and future BSM-related APIs.
By abstracting away from the resolution of BSM arguments, we
will (a) make BSMs less problematic for use in java.base (else
who will bootstrap the bootstraps?), and (b) allow BSMs to
emulate hardwired JVM linkage mechanisms with more
fidelity.

> I think both goals are important to use BSMs to expand species for Valhalla.

> This is probably a further step beyond JDK-8210685, because it aims to simplify the JVM specification by moving more API decisions up into a singular, global, library-defined uber-BSM.  Existing appeals to BSMs in the JVMS will be rewritten to simply specify the basic (unresolved) arguments to the singular uber-BSM.  There will have to be some sort of lower-level (non-resolving) reflection into the classfile the BSM operates on; this is a separate JEP or RFE.