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

Tobias Hartmann thartmann at openjdk.org
Tue Mar 14 13:35:06 UTC 2023


On Tue, 14 Mar 2023 13:22:20 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 SharedRuntime::generate_i2c2i_adapters

Good catch, Vladimir. New version looks good to me too.

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

Marked as reviewed by thartmann (Reviewer).

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


More information about the hotspot-compiler-dev mailing list