The primary issue with low hit rates and poor sample accuracy in the HotSpot JVM is that large portions of code lack descriptions (metadata), rendering it impossible to walk the stack.

When interrupts land in this type of code, the sampling attempt needs to abort because there is no way to determine how to move from that code to something Java-related.

To improve sampling accuracy and representativeness, we must improve the overall hit rate by increasing the surface area of successful samples.

This involves two levels:
* Adding structure and metadata descriptions to support routines, such as stubs and blobs.
* Adding metadata for describing intrinsics – for interpreter, C1, and C2.

Adding structure and metadata descriptions for stubs and blobs enables the parsing of leaf frames of these different types and mapping them onto a valid Java program point, i.e., their sender (caller) frames.

We suggest a standard frame layout and code-specific metadata formats to describe associated frames.

This includes:
* A standardized atomic frame setup (disallowing intermediate push/pop instructions)
* Structured block layout, single enter, single exit.
* Jumps must be contained inside the frame prologue and epilogue or be split into basic blocks.
* Code-specific metadata descriptions describing stack frame layout (including the epilogue).

From a sampling perspective, a standardized frame layout improves matters significantly because all instructions of the associated code are equivalent to safe points instructions and, therefore, safe for resolving the sender (caller) frame.

Additionally, we should record metadata for intrinsics in the interpreter and C1 and C2 compilers so that they become reified in the code stream. Then it becomes possible to map interrupts that land in, for example, any specialized array copy stub back onto the specific caller, whose call site correctly describes the intrinsic for System. arraycopy as a regular inlined method.