RFR: 8292077: G1 nmethod entry barriers don't keep oops alive [v4]

[Erik Österlund]

On Wed, 10 Aug 2022 15:59:02 GMT, Stefan Karlsson <stefank at openjdk.org> wrote:

>> Erik Österlund has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Thomas comments v2
>
> src/hotspot/share/gc/shared/barrierSetNMethod.cpp line 71:
> 
>> 69:       // concurrent marking. Using the keep alive side effects of a normal
>> 70:       // phantom load is less explicit, and doesn't actually do anything
>> 71:       // unless the returned value is used as an oop.
> 
> I think this is bit vague. Would it be OK if we explicitly spelled out the problem with the LoadOopProxy? Maybe something like this (feel free to tweak the actual text):
> 
> // Loads on nmethod oops are phantom strength.
> //
> // Note: that we could have used NativeAccess<ON_PHANTOM_OOP_REF>::oop_load(p),
> // but that would have *required* us to convert the returned LoadOopProxy to an oop,
> // or else keep alive load barrier will never be called. It's the LoadOopProxy-to-oop
> // conversion that performs the load barriers. This is too subtle, so we instead
> // perform an explicit keep alive call.

I used your comment but removed the colon in "Note: that". Thanks for the review!

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

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