RFR: Disable UseFastJNIAccessors for Shenandoah

[Aleksey Shipilev]

On 06/05/2018 12:40 PM, Roman Kennke wrote:
> Erik Österlund pointed out a nasty bug in the JNI fast-get-field code.
> This code is executed in thread-native state, which means it doesn't
> keep safepoints from happening. Between the forward pointer load and the
> actual field load, the thread may get descheduled, and 1 or more
> safepoints can happen, and the actual field access would crash. This
> problem hasn't happened in all those years (at least not knowingly), but
> *if* it happens, it's catastrophic.
> 
> See also:
> http://mail.openjdk.java.net/pipermail/hotspot-dev/2018-June/032763.html
> 
> We may have a solution, but currently have more important fires to put out.
> 
> 
> diff --git a/src/hotspot/share/gc/shenandoah/shenandoahArguments.cpp
> b/src/hotspot/share/gc/shenandoah/shenandoahArguments.cpp
> --- a/src/hotspot/share/gc/shenandoah/shenandoahArguments.cpp
> +++ b/src/hotspot/share/gc/shenandoah/shenandoahArguments.cpp
> @@ -172,6 +172,13 @@
>                   "are observed on class-unloading sensitive workloads");
>      FLAG_SET_DEFAULT(ClassUnloadingWithConcurrentMark, false);
>    }
> +
> +  // JNI fast get field stuff is not currently supported by Shenandoah.
> +  // It would introduce another heap memory access for reading the
> forwarding
> +  // pointer, which would have to be guarded by the signal handler
> machinery.
> +  // See:
> +  //
> http://mail.openjdk.java.net/pipermail/hotspot-dev/2018-June/032763.html
> +  FLAG_SET_DEFAULT(UseFastJNIAccessors, false);
>  }
> 
>  size_t ShenandoahArguments::conservative_max_heap_alignment() {

Looks good.

-Aleksey