-
Enhancement
-
Resolution: Not an Issue
-
P4
-
11, 17, 21
In JDK-8303154 it was reported that C1 and C2 compilations flush the ICache too often (in most cases there is no need to flush the ICache multiple times).
The cases 1,2 and 3 illustrated in the description ofJDK-8303154 have been addressed for C1 and C2 by https://github.com/openjdk/jdk/pull/12877
Nevertheless there are quite a few other places where the ICache is flushed multiple times possibly unnecessarily. Here is a non-exhaustive list:
1. Peter's comment inJDK-8303154 points to the StubGenerator.
2. a few additional flushes are called by "CodeBuffer::copy_code_and_locs_to", e.g.
ICache::invalidate_range(unsigned char *, int) icache_bsd_aarch64.hpp:41
Relocation::pd_set_data_value(unsigned char *, long, bool) relocInfo_aarch64.cpp:58
DataRelocation::set_value(unsigned char *, long) relocInfo.hpp:910
DataRelocation::set_value(unsigned char *) relocInfo.hpp:905
external_word_Relocation::fix_relocation_after_move(const CodeBuffer *, CodeBuffer *) relocInfo.cpp:772
CodeBuffer::relocate_code_to(CodeBuffer *) const codeBuffer.cpp:800
CodeBuffer::copy_code_to(CodeBlob *, bool) codeBuffer.cpp:734
CodeBuffer::copy_code_and_locs_to(CodeBlob *, bool) codeBuffer.hpp:703
...
3. a few more from TemplateInterpreter::initialize_code
ICache::invalidate_range(unsigned char *, int) icache_bsd_aarch64.hpp:41
AbstractAssembler::flush() assembler.cpp:110
CodeletMark::~CodeletMark() interpreter.cpp:106
CodeletMark::~CodeletMark() interpreter.cpp:102
TemplateInterpreterGenerator::generate_all() templateInterpreterGenerator.cpp:59
TemplateInterpreterGenerator::TemplateInterpreterGenerator() templateInterpreterGenerator.cpp:40
TemplateInterpreterGenerator::TemplateInterpreterGenerator() templateInterpreterGenerator.cpp:37
TemplateInterpreter::initialize_code() templateInterpreter.cpp:66
...
Further investigation is needed to check which flush is actually needed and which ones can be avoided (even conditionally).
The cases 1,2 and 3 illustrated in the description of
Nevertheless there are quite a few other places where the ICache is flushed multiple times possibly unnecessarily. Here is a non-exhaustive list:
1. Peter's comment in
2. a few additional flushes are called by "CodeBuffer::copy_code_and_locs_to", e.g.
ICache::invalidate_range(unsigned char *, int) icache_bsd_aarch64.hpp:41
Relocation::pd_set_data_value(unsigned char *, long, bool) relocInfo_aarch64.cpp:58
DataRelocation::set_value(unsigned char *, long) relocInfo.hpp:910
DataRelocation::set_value(unsigned char *) relocInfo.hpp:905
external_word_Relocation::fix_relocation_after_move(const CodeBuffer *, CodeBuffer *) relocInfo.cpp:772
CodeBuffer::relocate_code_to(CodeBuffer *) const codeBuffer.cpp:800
CodeBuffer::copy_code_to(CodeBlob *, bool) codeBuffer.cpp:734
CodeBuffer::copy_code_and_locs_to(CodeBlob *, bool) codeBuffer.hpp:703
...
3. a few more from TemplateInterpreter::initialize_code
ICache::invalidate_range(unsigned char *, int) icache_bsd_aarch64.hpp:41
AbstractAssembler::flush() assembler.cpp:110
CodeletMark::~CodeletMark() interpreter.cpp:106
CodeletMark::~CodeletMark() interpreter.cpp:102
TemplateInterpreterGenerator::generate_all() templateInterpreterGenerator.cpp:59
TemplateInterpreterGenerator::TemplateInterpreterGenerator() templateInterpreterGenerator.cpp:40
TemplateInterpreterGenerator::TemplateInterpreterGenerator() templateInterpreterGenerator.cpp:37
TemplateInterpreter::initialize_code() templateInterpreter.cpp:66
...
Further investigation is needed to check which flush is actually needed and which ones can be avoided (even conditionally).
- relates to
-
JDK-8303154 Investigate and improve instruction cache flushing during compilation
- Resolved
-
JDK-8317806 Aarch64 10x+ slower at clearing IC callsites than x64 causes long code cache unloading times
- In Progress