compilation-and-inlining-logslisted

# Compilation and Inlining Logs ## Purpose Read the compiler's own output instead of guessing at it. Three diagnoses look alike from the outside and lead to three different flags: the method never became native code at all; a specific call inside a tree that compiled fine was not inlined; or code that was already generated got invalidated afterwards. Confusing them is how a session ends with the wrong flag changed. The failure this prevents is the plausible-looking command that silently answers nothing — a tier filter on the wrong field, `-Xlog:jit` with no sub-tag, a JFR recording whose threshold drops every compilation, a directive that only applies to compilations that have not happened yet — and is then read as "there is nothing to see". ## Workflow 1. **Decide which question you are asking**, and reuse relevant existing captures before collecting more. For compilation-attempt timing and tier, use `PrintCompilation` or `-Xlog:jit+compilation`; their attempt headers precede completion, so confirm the outcome before claiming installed code. Use `PrintInlining` or `-Xlog:jit+inlining=debug` for decisions within an attempt. Currently listed nmethods and their tier/state are visible through `jcmd <pid> Compiler.codelist`; continuous production monitoring is JFR. A method can execute inlined in several callers without its own listed nmethod. 2. **Record the runtime and compilation mode** before interpreting a tier. On the usual server HotSpot with t