Currently, a JVM byte coded method has a single nullable pointer which refers to its unique compiled "nmethod", called Method::_code.

If the JVM needs to manage multiple compiled versions of a method, this design does not scale.  For example, we store OSR methods (perhaps several versions per method distinguished by entry point BCI) in a per-class side table.

In the future, mixtures of profiled and optimized execution modes may require two or more versions of a method (at different profile levels) to be kept available at the same time.  Also in the future, heterogeneous processing platforms may require optimized n-methods for more than one ISA at the same time.

To make this situation manageable, the _code field should be the root of a linked list of n-methods, reaching all versions of a given method.  An additional field nmethod::_next_code can link to additional versions.  The first item in the linked list can be privileged to interoperate with stubs and with normal calls on the CPU.

There are many use cases for a 1-N relation between one Method* meta-object and N code blobs:

A. differing optimization levels: keep a slower version handy if we need to fall back from a speculative optimization

B. differing profiling levels: the profiled version executes 1% of the time to gather more info, while the best optimized version runs 99% of the time

C. alternate entry points for on-stack replacement:  some hot methods must be entered at mid-execution from the interpreter; each BCI has a different entry point and different optimized code

D. coprocessor methods: code blobs for dispatch on GPUs or gate arrays

E. customized stream loops: optimizations of work-stealing scheduler methods for particular stream configurations

F. customized vector loops: vectorized optimizations of methods, to be used only in contexts where large data sets are input

G. native-mode methods:  callbacks from native code which are called outside the JVM's invariants

H. specialized methods:  hot generic methods which are specialized to particular layouts or data types, as with Arrays.sort on inline types

I. parametric VM specializations:  an explicitly specialized method will be specialized to its relevant "specialization anchor"; see https://github.com/openjdk/valhalla-docs/blob/main/site/design-notes/parametric-vm/parametric-vm.md

J. specializations to ad hoc preconditions, as in JDK-8255024

K. re-compilation of heuristically selected "template-like" methods when the JVM detects that it would be profitable to recompile a whole method against a refined (subclass) receiver type (e.g., because the "template-like" method depends on values or types which the subclass detectably specializes)

More background:

http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/2013-October/012078.html
https://mail.openjdk.java.net/pipermail/panama-dev/2020-June/009488.html