RFR: 8317368: [JVMCI] SIGSEGV in JVMCIEnv::initialize_installed_code on libgraal [v4]

[Tom Rodriguez]

On Mon, 15 Apr 2024 17:55:54 GMT, Tom Rodriguez <never at openjdk.org> wrote:

>> This fixes some lurking issues with JVMCI and nmethod related both BarrierSetNMethod and the garbage collection of nmethods.  In particular the stack walking in c2v_iterateFrames visits many frames and needs a KeepStackGCProcessedMark for safety.  Additionally, JVMCI interacts with nmethods in complex ways and needs some sort of strong root during these interactions.  A new JavaThread field has been added that mirrors the way JVMTI keeps nmethods alive.
>
> Tom Rodriguez has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains five commits:
> 
>  - Merge branch 'master' into tkr-nmethod-keep-alive
>  - Comment updates
>  - Merge branch 'master' into tkr-nmethod-keep-alive
>  - Move BarrierSetNMethod call into JVMCINMethodHandle::set_nmethod
>  - 8317368: [JVMCI] SIGSEGV in JVMCIEnv::initialize_installed_code on libgraal

You mean to add a level of indirection for the JVMCI specific fields?  Some of them would be fine with that but a few really want direct access.  We'd have to rework some interpreter assembly and code generation on the Graal side for those fields that accessed directly.  I could look into it at some point.

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

PR Comment: https://git.openjdk.org/jdk/pull/17714#issuecomment-2057587218