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

[Erik Österlund]

On Mon, 30 Jan 2023 21:03:00 GMT, Tom Rodriguez <never at openjdk.org> wrote:

> 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?

You are right, Deoptimization::query_update_method_data does looks like it has a bug. You need to either hold the extra_data_lock when using entries from the extra data section, or force cleaning first, so that existing entries won't move around until the next safepoint poll. The ciMethodData performs cleaning in its replica and keeping all of its type alive, making it safe to use, but extra care needs to be taken when using the MDO directly.

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

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