This issue affects performance research. This is a minimized version of what happens in JMH-driven code. See the test code here:
  http://cr.openjdk.java.net/~shade/8076988/TestCall.java

Both m() and m1() are very hot, we want to make sure both are compiled with C2. At the same time, we want to split the generated code, and forbid the inlining of m1() into m(). This can be done either via CompilerCommand, or via @DontInline annotation -- or some other way to tell CompilerOracle.

Without tiered, m1() gets compiled just fine:

$ java -XX:+PrintCompilation -XX:-TieredCompilation -XX:CompileCommand=dontinline,TestCall::m1 TestCall
     34 1 TestCall::m1 (1 bytes) <---- compiled with C2
     34 2 % TestCall::m @ 2 (18 bytes)
     35 2 % TestCall::m @ -2 (18 bytes) made not entrant
     35 3 TestCall::m (18 bytes)
     35 4 % TestCall::m @ 2 (18 bytes)
   2229 5 % TestCall::main @ 2 (18 bytes)
  15088 5 % TestCall::main @ -2 (18 bytes) made not entrant

With tiered, however, m1() seems to be stuck at level=1, i.e. C1:

$ java -XX:+PrintCompilation -XX:+TieredCompilation -XX:CompileCommand=dontinline,TestCall::m1 TestCall
...
     34 13 3 TestCall::m1 (1 bytes) <--- C1 with full profiling
     34 14 1 TestCall::m1 (1 bytes) <--- oops, back to C1
     34 13 3 TestCall::m1 (1 bytes) made not entrant
...

This is additionally verified by observing the generated code in such the methods, and seeing the C1-quality code there, while C2 code is expected. It is important to understand that the performance issue manifests when the inline of m1() is forbidden. Otherwise, the hot path would lie through the m() that inlined m1(), and the issue would burrow itself.