On Mon, 12 Jun 2023 15:55:49 GMT, Adam Sotona <asot...@openjdk.org> wrote:
>> Classfile context object and multi-state options have been discussed at >> https://mail.openjdk.org/pipermail/classfile-api-dev/2023-May/000321.html >> This patch implements the proposed changes in Classfile API and fixes all >> affected code across JDK sources and tests. >> >> Please review. >> >> Thanks, >> Adam > > 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 Since "not generating stack maps" really means to use an implicit stack map, I suggest renaming the `STACK_MAPS_NEVER` to `STACK_MAPS_IMPLICIT` to indicate such a confusing feature of StackMapTable. (In fact, the enum element names of StackMapsOption doesn't fit in with other options, they should be ALWAYS_STACK_MAPS, NEVER_STACK_MAPS, etc.) ------------- PR Comment: https://git.openjdk.org/jdk/pull/14180#issuecomment-1588916612
