RFR: JDK-8299229: Allow UseZGC with JVMCI and enable nmethod entry barrier support [v4]

[Tom Rodriguez]

On Mon, 23 Jan 2023 20:34:00 GMT, Tom Rodriguez <never at openjdk.org> wrote:

>> This exposes the required ZGC values to JVMCI and adds support for nmethod entry barriers.  The ZGC support is straightforward but the nmethod entry barrier required some reworking to fit better into JVMCI usage.  I also removed the epoch based barrier since it was no longer used with simplified the assumptions on the JVMCI side.  There is also a minor loom related fix to support post call nops included.  I could move that into a separate PR if that would be preferred.
>
> Tom Rodriguez has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains seven commits:
> 
>  - Handle concurrent unloading
>  - Merge branch 'master' into tkr-zgc
>  - Add missing declaration
>  - Replace NULL with nullptr in new code
>  - Merge branch 'master' into tkr-zgc
>  - Review fixes
>  - Allow UseZGC with JVMCI and enable nmethod entry barrier support

I see. MethodData::clean_extra_data repacks the extra data section so it's never safe to operate on that section without holding a lock.  So I don't think this affects the safety of these changes since JVMCI never reads types from that section.  With +UseJVMCICompiler there will never be speculative_trap_data in that section so it will never be shifted.  The only case where that could occur is in Truffle hosted mode where c2 is the JIT but Graal is used for Truffle.  This is presumably a long standing issue, assuming that we actually even use that path.  I'll investigate when we actually read bits data from that section, if at all, and either remove that path or make it safe.

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

PR: https://git.openjdk.org/jdk/pull/11996