The GraalVM Truffle framework compiles guest language functions starting from certain well known Truffle AST entry functions like `OptimizedCallTarget::profiledPERoot()`.

Unfortunately, all the nmethods for guest language functions will therefore end up having the same name: `com.oracle.truffle.runtime.OptimizedCallTarget::profiledPERoot`.

This can be quite confusing for tools like profilers, because they will aggregate samples for different instances of  `com.oracle.truffle.runtime.OptimizedCallTarget::profiledPERoot` nmethods under the same name. E.g. if the execution of a JavaScript program triggers the compilation of 100 different JavaScript function they will appear as a single method under the name `OptimizedCallTarget::profiledPERoot()` in the profile.

This behavior is also confusing from a user perspective if using command line flags like `-XX:+PrintCompilation` because it suggests that a single method like  `com.oracle.truffle.runtime.OptimizedCallTarget::profiledPERoot` gets compiled houndreds of times where in realty all these compilations are for different guest language functions.

Fortunately, nmethods created from such "hosted" JVMCI compilations (i.e. JVMCI compilations not triggered by the `CompilerBroker` but e.g. by the Truffle framework) have an addition `jvmci_name` field, which contains the name of the guest language function.

I propose to add this additional `jvmci_name` to the regular nmethod name in the case of "hosted" JVMCI compilations to make them distinguishable in tools and and various logs.