The CompilationPolicy hierarchy supports varying levels of sophistication for selecting when methods are to be compiled and in what order. However, it is restricted to using (mostly) compiler independent metrics when making decisions.

A compiler may be able to make a better decision in terms of when it's worth compiling a method. For example, an optimizing compiler such as Graal may decide after bytecode parsing that:

1. it won't do a better job than a lower tier compiler (e.g., C1), or
2. the method has constructs it doesn't support, or
3. Graal is likely to inline the method at all call sites and so there's no point in directly compiling it.

Based on the above, Graal may want to communicate to the CompileBroker that the method should be compiled later (e.g., when there's nothing else on the queue), compiled at a lower compilation level or not compiled at the current compilation level.

The CompilationRequestResult object returned by JVMCICompiler.compileMethod API should be expanded to encode the above ideas. This is the right place to support such communication as it is executed on a compiler thread and thus does not slow down handling of compilation counter overflows on an application thread.