Atomic-free JNI

[gacholio]

Prior to this work, all synchronization of entering and exitting the VM was performed by using atomic compare-and-swap operations, which are extremely heavyweight. A single machine word contained the state of each thread (in or out of the VM) and any requests from other threads (e.g. exit the VM to allow the GC to run).

This feature replaces the VM entry/exit for JNI natives with a modified Dekker algorithm to avoid the use of atomic operations. Along with the existing state field, a new "inNative" field is added to each thread to indicate whether the thread is cooperating with the VM (inNative == false) or executing native code (inNative == true). Memory barriers are used to ensure the ordering visibility of the two fields. Where possible, the explicit memory barriers on the mutator threads are replaced by system calls to force ordering of execution on all threads in the process (see https://docs.microsoft.com/en-us/windows/desktop/api/processthreadsapi/nf-processthreadsapi-flushprocesswritebuffers).

[pshipton]

@gacholio are we keeping this issue open until ARM and OSX are addressed?

[gacholio]

Ask @DanHeidinga - he made me open it.

[DanHeidinga]

This should stay open until all the PRs for the Atomic Free JNI work have been listed in this item so that there's a way to find the implementation.

ARM / OSX support can be added under separate issues when those platforms get added to the build system.

[pshipton]

@gacholio as per #2576 (comment) can you please add the list of PRs so we can close this.

[pshipton]

I assume its something like https://github.com/eclipse/openj9/pulls?utf8=%E2%9C%93&q=is%3Apr+atomic+author%3Agacholio

[gacholio]

Close enough

[pshipton]

#1109
#1535
#1559
#1567
#1605
#1651
#1680
#1687
#1726
#1762
#1793
#1798
#1810
#1823
#1857
#1869
#1895
#1923
#1964
#2039
#2077
#2333
#2353
#2575
#2663