RFR: 8329628: Additional changes after JDK-8329332

[Erik Österlund]

On Fri, 5 Apr 2024 23:39:49 GMT, Vladimir Kozlov <kvn at openjdk.org> wrote:

> Additional clean up based on comments (mostly Stefan's) during reviews for [JDK-8329332: Remove CompiledMethod and CodeBlobLayout classes](https://bugs.openjdk.org/browse/JDK-8329332).
> - Renamed `CompiledMethod_lock` to `NMethod_lock`.  (I decided to not change JVMTI's `CompiledMethod[Load|Unload]` names).
> - Renamed `NMethodIterator::all_blobs` to `NMethodIterator::all`.
> - Moved `get_deopt_original_pc()` method from `nmethod` to `frame` class.
> - Reverted `CodeCache::find_nmethod()` to previous functionality to allow return `nullptr` and be consistent with `find_blob()`.
> - Cleanup some `(nmethod*)` casts.
> - Use `for (CodeHeap* heap : *_nmethod_heaps) ` in `CodeCache::nmethod_count()` (it was @stefank suggestion,  I don't know how this C++ magic works). I verified it running with `-XX:+PrintNMethodStatistics`.
> 
> Testing tier1-3,xcomp,stress

I was never a fan of the CompiledMethod_lock name, as it is quite general but only protects a very specific thing: the state. With the NMethod_lock it gets slightly more awkward since the concurrent GCs already have an "nmethod lock" in the GC data of nmethods. Could this lock be called NMethodState_lock instead, to more clearly describe what exactly it is about nmethods that it guards?

-------------

PR Review: https://git.openjdk.org/jdk/pull/18665#pullrequestreview-1985775840