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

[Vladimir Ivanov]

Aleksey,

Nice patch!

Some comments below.

Do you really need there #define/#undef pairs? Why not just declare a 
local variable?

I would invert if-else branches, so original logic is on a true branch. 
IMO, it simplifies reading the code.

Also, we discussed in person the change for nodes with 
is_iteratively_computed() == true. I'm not sure whether it is "safe" or 
not, but I would retain original logic for 
-XX:-FuzzInstructionScheduling case.

Best regards,
Vladimir Ivanov

On 2/27/13 1:35 PM, Aleksey Shipilev wrote:
> 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.
>