RFR: JDK-8303154: Investigate and improve instruction cache flushing during compilation [v2]

[Vladimir Kozlov]

On Mon, 13 Mar 2023 13:52:59 GMT, Damon Fenacci <duke at openjdk.org> wrote:

>> It was noticed that we flush the instruction cache too much for a single C1 compilation. The same is true for the C2 compilation.
>> There are several places in the code where the instruction cache is called and many of them are very intertwined (see [bug report](https://bugs.openjdk.org/browse/JDK-8303154)).
>> 
>> This PR is meant to be a "minimum" set of changes that improve the situation without introducing excessive extra information to keep track of the origin of the call through call stacks. This is done by avoiding calls to flush the ICache at `Compilation::emit_code_epilog` and  when calling `CodeCache::commit` as flushing is done anyway when copying from the temporary buffer into the code cache in `CodeBuffer::copy_code_to`. This results in flushing the ICache only once instead of 3 times for a C1 compilation and twice for a C2 compilation. Additionally this halves the number of flushes during adapters generation (lots of calls).
>> 
>> This change decreases the number of calls to flush the ICache for a simple _Hello world_ program on Mac OSX aarch64 from 3569 to 2756 on C1 (22.8% improvement) and from  3572 to 2685 on C2 (24.1% improvement).
>
> Damon Fenacci has updated the pull request incrementally with one additional commit since the last revision:
> 
>   JDK-8303154: remove flush in CodeCache::commit() instead of CodeBuffer::copy_code_to()

Good. What are new numbers of of calls to flush the ICache?

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

Marked as reviewed by kvn (Reviewer).

PR: https://git.openjdk.org/jdk/pull/12877