On Thu, 28 Sep 2023 22:32:29 GMT, Chris Plummer <[email protected]> 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