The diagnostic commands `Compiler.codelist`, `Compiler.CodeHeap_Analytics` and `Compiler.perfmap` are handy for analyzing the CodeCache or creating a symbol file for the perf tool. However, with the Truffle framework which uses the GraalVM compiler in "hosted" mode, we can end up with hundreds if not thousands of nmethods which are all linked to the same Java method (most prominently `com.oracle.truffle.runtime.OptimizedCallTarget.profiledPERoot()`). All these nmethods are currently indistinguishable by the two aforementioned diagnostic commands.

But nmethods compiled by the GraalVM compiler have a special "JVMCI name" attached to them, which in the case of Truffle corresponds to the guest language function name. Print this "JVMCI name" in addition to the true Java method name to make it easier to distinguish various nmethods compiled by Truffle or other frameworks which use the GraalVM compiler in hosted mode.

For the `Compiler.perfmap` command, it should be mentioned that the format of the created perfmap file is specified here:
https://github.com/torvalds/linux/blob/master/tools/perf/Documentation/jit-interface.txt

It only mandates that each line starts with a start and size number in hex and interprets the whole rest of the line (which can even include special characters) as a "symbolname". Taking into account that we already today produce "symbol names" as different as "throw_range_check_failed Runtime1 stub", "Signature Handler Temp Buffer", "I2C/C2I adapters" or "boolean java.lang.invoke.VarHandleInts$FieldInstanceReadWrite.compareAndSet(java.lang.invoke.VarHandle, java.lang.Object, int, int)", adding a potential jvmci suffix like "jvmci_name=myFancyJSFunction()#2" will not cause any compatibility issues.

And the output of `Compiler.CodeHeap_Analytics` is unparsable anyway :)