RFR: 8310239: Add missing cross modifying fence in nmethod entry barriers [v2]

Erik Österlund eosterlund at openjdk.org
Fri Oct 20 14:59:38 UTC 2023


On Tue, 10 Oct 2023 04:31:42 GMT, Dean Long <dlong at openjdk.org> wrote:

> > The assumption is that if the nmethod immediate oops are patched first, and the guard value (immediate of the cmp instruction) is patched after, then if a thread sees the new cmp instruction, it will also see the new oop immediates.   And that is indeed what the "asynchronous" cross modifying code description ensures will work in the AMD APM. So that all checks out.
> 
> I guess this is a separate issue from this patch, but where does the AMD APM guarantee that?

In the APM, volume 2 (cf. https://www.amd.com/content/dam/amd/en/documents/processor-tech-docs/programmer-references/24593.pdf), section 7.6.1 under "Asynchronous modification", it says ""

> > The assumption is that if the nmethod immediate oops are patched first, and the guard value (immediate of the cmp instruction) is patched after, then if a thread sees the new cmp instruction, it will also see the new oop immediates.   And that is indeed what the "asynchronous" cross modifying code description ensures will work in the AMD APM. So that all checks out.
> 
> I guess this is a separate issue from this patch, but where does the AMD APM guarantee that?

Hmm, it used to be in Volume 2, section 7.6.1. But in the latest revision, 3.41 from this summer, I can't find it any more. Strange.

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

PR Comment: https://git.openjdk.org/jdk/pull/14543#issuecomment-1772895987


More information about the hotspot-dev mailing list