RFR: 8299032: Interface IN_NATIVE oop stores for C2

[Erik Österlund]

On Tue, 10 Jan 2023 01:56:11 GMT, Kim Barrett <kbarrett at openjdk.org> wrote:

>> Loom added the first IN_NATIVE oop store to C2 code, when switching the current virtual thread of a platform thread. Instead of interfacing this properly, a raw store was used. But a future GC algorithm, such as generational ZGC, might not work well with raw stores. We should add support to the access API for this. Looks like Shenandoah was already missing something here as they do concurrent root processing requiring SATB barriers on IN_NATIVE oop stores. It is not in the scope of this PR to fix the Shenandoah bug - someone working on Shenandoah should do this. This PR merely adds an interface such that GCs that need to do something different here, can do that. Serial, Parallel and G1 don't need to do anything for IN_NATIVE stores as they do STW root processing. ZGC doesn't (yet) have store barriers at all, and hence doesn't need to do anything special either.
>
> src/hotspot/share/opto/library_call.cpp line 3353:
> 
>> 3351:   thread_obj_handle = _gvn.transform(thread_obj_handle);
>> 3352:   const TypePtr *adr_type = _gvn.type(thread_obj_handle)->isa_ptr();
>> 3353:   access_store_at(NULL, thread_obj_handle, adr_type, arr, _gvn.type(arr), T_OBJECT, IN_NATIVE | MO_UNORDERED);
> 
> Old code has a `control()` constraint on the store.  Is it okay to drop that?

The first parameter to access_store_at, is the containing object, not the control (which might be different to the address). As for IN_NATIVE stores, there is no containing object, which is what the NULL denotes. In the backend, it does indeed attach the current control inside of BarrierSetC2::store_at_resolved.

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

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