-
Bug
-
Resolution: Fixed
-
P2
-
9
-
b146
-
Verified
In various microbenchmarks we've seen nmethod::is_compiled_by_jvmci be suspiciously hot (5-10% of total CPU cycles)
Analyzing the situation it appears we're often directly interested in compiler type which compiled an nmethod, and only for debug printouts do we need to get to the actual compiler object, thus it appears fruitful to consider only storing the compiler type in the nmethod and inline the constant comparisons, and then resolve the compiler from type when needed for debugging (as there seems to be a 1:1 mapping from type to the compiler object).
This could potentially reduce nmethod footprint, too.
Analyzing the situation it appears we're often directly interested in compiler type which compiled an nmethod, and only for debug printouts do we need to get to the actual compiler object, thus it appears fruitful to consider only storing the compiler type in the nmethod and inline the constant comparisons, and then resolve the compiler from type when needed for debugging (as there seems to be a 1:1 mapping from type to the compiler object).
This could potentially reduce nmethod footprint, too.
- duplicates
-
JDK-8031211 replace nmethod::_compiler with a flags field that stores AbstractCompiler::Type values instead
-
- Closed
-
- relates to
-
JDK-8259287 AbstractCompiler marks const in wrong position for is_c1/is_c2/is_jvmci
-
- Resolved
-