[foreign-memaccess+abi] RFR: 8293367: Enable native access for modules not in the boot layer [v2]

[Maurizio Cimadamore]

On Wed, 21 Sep 2022 13:16:44 GMT, Jorn Vernee <jvernee at openjdk.org> wrote:

>> src/java.base/share/classes/java/lang/Module.java line 275:
>> 
>>> 273:     public boolean isNativeAccessEnabled() {
>>> 274:         Module target = enableNativeAccessHolder();
>>> 275:         synchronized(target) {
>> 
>> I'm not sure how much of a problem this is, but I guess since the module object is publicly accessible, it's theoretically possible that some user code is also locking on it.
>> 
>> For the record; alternative could be to add a private field to module with a dedicated lock Object for enabling native access. Though, I don't think that's needed at the moment.
>
> Or, maybe it's possible to do this in a lock-free manner altogether? i.e. `implAddEnableNativeAccess` and  would use a volatile write, and `isNativeAccessEnabled` and `ensureNativeAccess` would use volatile reads instead of synchronized blocks. (assuming we can use `Unsafe` at this point).

That's a thought that occurred to me as well. E.g. declare the variable w/o `volatile`, but then use either Unsafe, or VarHandle to access the variable in `volatile` mode when required. That said, note that this will not get rid of all the synchronization needs: we would still need to synchronize on a module in the native access check to make sure that we issue at most one warning. But perhaps we can have a private lock just for that.

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

PR: https://git.openjdk.org/panama-foreign/pull/729