RFR(M) 8227003: [Graal] java/lang/invoke/VarHandles/VarHandleTestByteArrayAsInt.java time out

[Igor Veresov]

> On Oct 4, 2019, at 10:55 AM, Tom Rodriguez <tom.rodriguez at oracle.com> wrote:
> 
>> I’d like to introduce a -XX:TieredMode=<number> flag to control this. See the webrev for its description.
> 

Command line parameter naming is the hardest problem in computer science indeed.

> I think the policy you are suggesting sounds reasonable to me, but I find the use of a bit mask to select it to be confusing.  Several of the bit mask states seem invalid like TieredMode=7 seems to just be TieredMode=1 apart from inconsistent flags settings. How is TieredMode=1 different from TieredStopAtLevel=1?  Isn't TieredMode=6 equivalent to the old -TieredCompilation?  We've disabled level 1-3 for everyone but JVMCI and then we've disable the special level 1 for JVMCI, so isn't level 4 the only thing left?
> 

So, first thing is that I’d like to get rid of the non-tiered policy in the future, so the goal of TieredMode was to be able to select all the possible execution modes. The ability to combine 2 | 4 is intentional. Some tests want to switch C1 off entirely. The two tests in this webrev are one of those. It is also useful if you suspect that C1 is a problem and want to turn it off. TieredMode=1 for now is the same as TieredStopAtLevel=1, yes, but my intention is to make the adjustments to the policy to do it more refined. TieredStopAtLevel=1 is really a debug flag that people started using to get a C1-only mode, but it has not been tuned for that really, it just limits the compile level at the last moment before a compile request is submitted. Anyways, my intent was to make TieredMode to be a *set* of flags that adjust the policy behavior. You’re right that some bit combinations are making the policy to ignore some other bits (although all the bit combinations are valid, there is even a test that checks that).  

> Why not have some symbolic names with a clearer description of what those modes are?

That’s a good idea, except I wan’t able to come up with the good names. I don’t want to mention C1 or C2 in the names of these flags, because it may all be different modes of Graal in the future. If we name the options now we are struck with them forever. Bits are on the other hand anonymous. 

May be 0 - default, 1 - simple, 2 - no_intermediate, 4 - no_force_simple ?

>  Do we even need/want this much flexibility exposed? Maybe -TieredCompilation  defaults to the new behaviour in the presence of +UseJVMCICompiler and a new StrictTieredCompilation gives you the old behaviour.
> 

I had this in one of the revisions. I think it’s more confusing. 

-XX:-TieredCompilation - C1 only for Graal
-XX:-StrictTieredCompilation - no C1 at all.
-XX:+TieredCompilation - normal behavior

And then there are combinations of these flags with ambiguous meanings.  It becomes this “I seriously mean no tiered this time” flag. I’m not a big fan of how it reads.

Igor
  

> tom
> 
> 
>> To make the tests work out-of-the-box I check if the flags -XX:-TieredCompilation and -XX:+UseJVMCICompiler are on the command line and turn the tiered compilation back on in non-tiered emulation mode. A warning is issued to alert the user to the change. This mode is also a step towards being able to remove the non-tiered policy.
>> Webrev: http://cr.openjdk.java.net/~iveresov/8227003/webrev.00/ <http://cr.openjdk.java.net/%7Eiveresov/8227003/webrev.00/>
>> JBS: https://bugs.openjdk.java.net/browse/JDK-8227003
>> igor