RFR (S): CR 8009120: Fuzz instruction scheduling in Hotspot compilers

[Aleksey Shipilev]

Hi,

Haven't got any response from the last note, so here's the more complete
changeset. Ping me if something should be done to match the integration
requirements, control flow rewired to match usual conventions, etc.

The idea for the fuzzer is quite simple:
  - LCM schedules the instructions within the basic block, choosing the
schedule based on the node input count, latency, etc; we can hijack the
selection process and randomize the choice.
  - GCM selects the basic block up the dominator tree with the best
frequency/latency to fit the Node in; we can hijack this and randomize
the placement.

Webrev:
  http://cr.openjdk.java.net/~shade/8009120/webrev.00/

I have a question about self->is_iteratively_computed() in GCM though.
This condition seems to ensure correctness, and should be enforced even
when LCA_freq < least_freq?

Testing:
  - full HotSpot JPRT cycle in oob mode (still running, ~80%, no issues)
  - full HotSpot JPRT cycle with forced -XX:+FuzzInstructionScheduling
  - ad-hoc java-concurrency-torture with -XX:+FuzzInstructionScheduling

The observation is that all tests are fine the fuzzing either turned
on/off, so intra-thread semantics is not broken. Concurrency torture
tests start to fail with fuzzing, marking the inter-thread semantics is
violated by compiler (these are the cases we want to catch in that
tests), these failures are similar to CR 8007898:
  http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8007898

Thanks,
-Aleksey.