request for review (L): 7121756 Improve C1 inlining policy by using profiling at call sites

[Roland Westrelin]

> src/share/vm/c1/c1_GraphBuilder.cpp:
> 
> +  if (C1TypeProfileInlining && 
> +      code != Bytecodes::_invokestatic &&
> +      code != Bytecodes::_invokespecial &&
> +      code != Bytecodes::_invokedynamic &&
> +      (code != Bytecodes::_invokevirtual || !target->is_loaded() || !target->is_final_method())) {
> 
> Can this be reversed and simplified?

I'll see what I can do when I rework this.

> src/share/vm/c1/c1_LIR.cpp:
> 
> +  assert (code == lir_checkcast ||code == lir_instanceof, "expects checkcast or instanceof only");
> 
> Spacing is odd.

Ok.

> src/share/vm/ci/ciMethod.cpp:
> 
> +bool ciMethod::profile_is_hot_helper(ciProfileData* data, int bci, bool &warm, bool full) {
> 
> What is "full"?  Maybe you can find a better name.

When a method is compiled, if some profiling data at a call site is available, the compiler checks if the call site is hot or not. The call site may have been seen C1ProfileHotFrequency (i.e. we've collected full profile information) or it may be have been seen a number of times < C1ProfileHotFrequency. We consider both call sites with full and partial profile data for inlining (assuming we have sufficient profile data: number of times seen >= C1ProfileHotFrequency/2). The full argument request that only call sites with full profiling data be considered. That's used for virtual calls where we want to be sure when we inline because the profiling data says only a single klass was seen that we have sufficient data.

> src/share/vm/code/compiledIC.cpp:
> 
> +bool CompiledProfile::is_profiled(NativeCall* call) {
> +#ifdef COMPILER2
> +  return false;
> +#endif
> +#ifdef COMPILER1
> +  if (!C1ProfileInlining) return false;
> 
> I think this will produce a compiler warning (or error) when compiling C2 since it defines -DCOMPILER2 -DCOMPILER1.

Ok.

> 
> +#ifdef ARM
> +    // The first word of a static call stub has no reloc info. So if
> +    // we don't find a reloc info we know, it's a static call stub.
> +    return obj != NULL;
> +#endif
> 
> Why does ARM not require a reloc info?

On other platforms, the first instruction of the static call stub loads an oop with a mov or similar sequence of instructions. On ARM, to accommodate all ARM instruction sets, the oop is loaded with a PC relative ldr. The oop itself is embedded in the instruction stream at the end of the stub (so that it is never "executed"). So the reloc is where the oop is embedded not on the first instruction.

Roland.