On Fri, 8 Jan 2021 06:07:23 GMT, Igor Veresov <ivere...@openjdk.org> wrote:
>> Marking as reviewed, but only for the jvmti tests. I don't believe there are >> any other svc changes in this PR. > > Please find the answers in-line. > >> _Mailing list message from [David Holmes](mailto:david.hol...@oracle.com) on >> [shenandoah-dev](mailto:shenandoah-...@openjdk.java.net):_ >> >> Hi Igor, >> >> On 8/01/2021 6:36 am, Igor Veresov wrote: >> >> > This change removes the legacy compilation policy and an emulation mode to >> > the tiered policy to simulate the old behavior with >> > ```-XX:-TieredCompilation```. The change removed a bunch of interpreter >> > code, devirtualizes the compilation policy API, adds a consistent way to >> > query compiler configuration with the new ```CompilerConfig``` API. >> >> Can you clarify, for non-compiler folk, what all the alternative configs >> actually mean now. I'm a bit confused by this definition: >> >> define_pd_global(bool, TieredCompilation, >> COMPILER1_PRESENT(true) NOT_COMPILER1(false)); > > That's in a c2_globals_*.hpp, which is only included if C2 is present. Given > that, if C1 is present as well the flag is set to true. >> >> as I expected tiered compilation to require COMPILER1 and COMPILER2. >> > Right. That's exactly what's happening. > >> Also I see interpreter code that used to be guarded by TieredCompilation >> now being executed unconditionally, which seems to assume C1 or C2 must >> be present? >> > > Counters and compilation policy callbacks are historically guarded by > UseCompiler and UseLoopCounter flags, which are set to false if there are no > compilers present. I haven't changed the semantics. > >> Overall it is a big change to digest, but after skimming it looks like a >> few of the refactorings could have been applied in a layered fashion >> using multiple commits to make it easier to review. >> > > Frankly, I don't know how to split it into smaller pieces. There are > surprisingly lots of interdependencies. However, the best way to think about > it is that there are three major parts: 1. CompilerConfig API that is an > abstraction over compiler configuration (what's compiled in, what flags are > present that restrict compiler usage, etc); 2. The legacy policy removal. 3. > Emulation of the old JVM behavior. > > As far as the runtime part of the change is concerted, it's pretty much only > the legacy policy removal. In particular, the parts of the interpreter that > dealt with the old policy (basically everything in the interpreter that was > under !TieredCompilation has gotten removed). > > Igor > >> Thanks, >> David >> ----- To clarify the possible configs. 1. There is only one policy now. Functions with both compilers or a single compiler. 2. The best way to control the operation mode is with the ```-XX:CompilationMode=``` flag. Possible values so far are: normal (aka default), high-only (c2 or graal only), quick-only(c1 only), high-only-quick-internal (a special mode for jar graal where only graal itself is compiled by c1, but the user code is compiled with graal). 3. There is a mode that emulates the behavior when the user specifies -TieredCompilation. That's basically the high-only mode. 4. There is also support for legacy policy flags such as CompileThreshold, which would properly setup the policy parameters to match the old behavior. ------------- PR: https://git.openjdk.java.net/jdk/pull/1985
