RFR: [8u] Critical backports to sh/jdk8u

[Christine Flood]

void ShenandoahHeap::try_inject_alloc_failure() {
+   if (ShenandoahAllocFailureALot && !cancelled_concgc() &&
((os::random() % 1000) > 950)) {
+     _inject_alloc_failure.set();
+     Thread::current()->_ParkEvent->park(1);
+     if (cancelled_concgc()) {
+       log_info(gc)("Allocation failure was successfully injected");
+     }
+   }
+ }

Is it possible that there is a race and we get to the test for
cancelled_concgc before it actually gets set?

Is there any reason not to try JCStressTests with frequent allocation
failures?

I'm just curious.  I don't see any reason to stop the patch moving forward.


Christine



On Fri, Jan 26, 2018 at 11:48 AM, Aleksey Shipilev <shade at redhat.com> wrote:
> http://cr.openjdk.java.net/~shade/shenandoah/backports/jdk8u-20180126-crit/webrev.01/
>
> We do not have much time to complete bulk backports, so let us backport only the critical
> bug/perf/test fixes:
>
> dc779781dd5e: Do not put down update-refs-in-progress flag concurrently
> 1d1238a0603b: Defer cleaning of system dictionary and friends to parallel cleaning phase
> 1a6a9f288dd2: Bitmap size might not be page aligned when large page is used
> 30e8ba6e2794: VerifyJCStressTest should test all heuristics
> 820129a799b1: Allocation failure injection machinery
>
> Let's do these right now. We shall backport other things as time allows.
>
> Testing: hotspot_gc_shenandoah {fastdebug|release}
>
> Thanks,
> -Aleksey
>