[lworld] RFR: 8235914: [lworld] Profile acmp bytecode

[John R Rose]

On Fri, 11 Sep 2020 07:58:46 GMT, Roland Westrelin <roland at openjdk.org> wrote:

> This includes:
> - a new ProfileData structure to profile both inputs to acmp
> - profile collection at acmp in the interpreter on x86
> - profile collection at acmp in c1 generated code on x86
> - changes to c2's acmp implementation to leverage profiling (both existing profiling through type speculation and new
>   profile data at acmp)
> - small tweaks to the assembly code generated for acmp
> - a change to the implementation of LIRGenerator::profile_null_free_array() so it doesn't use a branch (which is
>   dangerous given the register allocator is not aware of branches added at the LIR level)
> - new tests
> 
> Profile collection happens unconditionally. Leveraging profiling at acmp is under UseACmpProfile which is false by
> default.

When the JIT speculates on an acmp profile, I suppose the independent type profiles will help to make some cases more
profitable to test:  If an inline type is common, you test for it first and inline the rest.

But I don't think a good result requires independent type profiles for the two operands.  I would think that the
relevant history would consist of (a) the number of acmp attempts, and (b) for each inline type *for which the operands
had that as their common type* the frequency of encountering that type.  That's really just a single klass profile
(with counters).

This other form would be somewhat preferable because it would use less footprint and require less bookkeeping, and it
would capture sharper information for the JIT, than two independent profiles.  The weakness of independent profiles is
you don't know how often the two operands end up with the same type.

Just a suggestion.

-------------

PR: https://git.openjdk.java.net/valhalla/pull/185