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 don't understand how this concurrent repacking of the extra data is safe in general.  If an existing record in the extra data section can move at any time then don't operations on that record have to be performed under the lock?  Deoptimization::query_update_method_data may allocate a new record and then use it without caring whether it's in the extra data section or not.  There's some similar JVMCI updates of the exception_seen that have the same problem.  We're probably less exposed since we don't normally have speculative trap entries that would result in repacking.  So it seems to me that every caller of allocate_bci_to_data must be holding the extra_data_lock so it can safely use the data.  Am I missing something?

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

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