On Tue, 13 Jun 2023 09:19:00 GMT, Chen Liang <li...@openjdk.org> wrote:
>> Adam Sotona has updated the pull request with a new target base due to a >> merge or a rebase. The pull request now contains 38 commits: >> >> - Merge branch 'master' into JDK-8308899-context >> - Revert of DirectCodeBuilder.needsStackMap pre-calculation >> - Revert "removal of ClassHierarchyImpl.DEFAULT_RESOLVER" >> esolver.java >> - Revert "proposed semi-synchronized caching, where the map is not locked >> during delegate call" >> >> This reverts commit ae2877512d978468743bcaa7e0f596729f12ee72. >> - fixed StackMapsOption dispatching in DirectCodeBuilder >> - proposed semi-synchronized caching, where the map is not locked during >> delegate call >> - used Factory.INSTANCE for system ClassHierarchyResolver cache >> - Revert "ClassHierarchyResolver::ofSystem is now thread-unsafe" >> >> This reverts commit f3099cd5b252924392995bf65edc710c27822d2b. >> - ClassHierarchyResolver::ofSystem is now thread-unsafe >> - removal of ClassHierarchyImpl.DEFAULT_RESOLVER >> introduction of ClassHierarchyResolver::ofSystem factory method >> ClassfileImpl does not pre-initialize ClassHierarchyResolverOption with >> default >> - ... and 28 more: https://git.openjdk.org/jdk/compare/5d5ae352...9e0d141e > > src/java.base/share/classes/jdk/internal/classfile/impl/DirectCodeBuilder.java > line 349: > >> 347: } >> 348: >> 349: private boolean writeOriginalAttribute(BufWriterImpl buf) { > > As a result (see previous comment), we will run into a redundant stack map > generation when the original stack map table is trivial (absent). Maybe we > want to consider user-configured selective stack map regeneration to replace > this faulty logiic. I've fixed the logic in the commit below. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/14180#discussion_r1228002306
