On Thu, 28 Sep 2023 22:32:29 GMT, Chris Plummer <cjplum...@openjdk.org> wrote:
>> Please review this change to fix the operands of the bytecodes that operate >> on fields when dumping a class using SA. >> >> Testing: hotspot_serviceability >> >> I have also verified that >> `test/hotspot/jtreg/serviceability/sa/ClhsdbDumpclass.javaClhsdbDumpclass.java`, >> which is in the problem list because of this issue, passes with this change. >> I have also verified it by dumping the class that has getstatic/putstatic >> bytecodes and comparing the bytecodes manually with the original classfile. > > src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/tools/jcore/ByteCodeRewriter.java > line 137: > >> 135: case Bytecodes._invokedynamic: { >> 136: int cpci = method.getNativeIntArg(bci + 1); >> 137: cpoolIndex = (short) >> cpCache.getIndyEntryAt(~cpci).getConstantPoolIndex(); > > Is this really suppose to be `~cpci` and not just `cpci`? That's right. See https://github.com/openjdk/jdk/blob/ecb5e8a03f67c92d7956201de1fa7d07cc6af9cb/src/hotspot/share/prims/jvmtiClassFileReconstituter.cpp#L1053 and https://github.com/openjdk/jdk/blob/ecb5e8a03f67c92d7956201de1fa7d07cc6af9cb/src/hotspot/share/oops/constantPool.hpp#L256 I tend to use `JvmtiClassFileReconstituter` as the reference for the code involved in dumping the classfile, and that makes things easier to follow and implement. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/15973#discussion_r1340737723