On Wed, 20 Dec 2023 02:57:29 GMT, Andrei Pangin <apan...@openjdk.org> wrote:
>> Dmitry Chuyko has updated the pull request with a new target base due to a >> merge or a rebase. The pull request now contains 33 commits: >> >> - Merge branch 'openjdk:master' into compiler-directives-force-update >> - Merge branch 'openjdk:master' into compiler-directives-force-update >> - Merge branch 'openjdk:master' into compiler-directives-force-update >> - Merge branch 'openjdk:master' into compiler-directives-force-update >> - Merge branch 'openjdk:master' into compiler-directives-force-update >> - Merge branch 'openjdk:master' into compiler-directives-force-update >> - Merge branch 'openjdk:master' into compiler-directives-force-update >> - Merge branch 'openjdk:master' into compiler-directives-force-update >> - Merge branch 'openjdk:master' into compiler-directives-force-update >> - Merge branch 'openjdk:master' into compiler-directives-force-update >> - ... and 23 more: https://git.openjdk.org/jdk/compare/fde5b168...44d680cd > > src/hotspot/share/code/codeCache.cpp line 1409: > >> 1407: while(iter.next()) { >> 1408: CompiledMethod* nm = iter.method(); >> 1409: methodHandle mh(thread, nm->method()); > > If there are two CompiledMethods for the same Java method, will it be > scheduled for recompilation twice? Related question: if `nm` is an OSR > method, does it make sense to go directly for deoptimization rather than > compiling a non-OSR version? If there are multiple method versions, it will be recompiled several times. The alternative is too keep some additional information which may complicate the code. OSRs is a good catch, I changed their handling to deopt. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/14111#discussion_r1434887812
