On Thu, 6 Jul 2023 05:18:01 GMT, Jean-Philippe Bempel <jpbem...@openjdk.org> wrote:
> Fix a small leak in constant pool merging during retransformation of a class. > If this class has a catch block with `Throwable`, the class `Throwable` is > pre-resolved in the constant pool, while all the other classes are in a > unresolved state. So the constant pool merging process was considering the > entry with pre-resolved class as different compared to the destination and > create a new entry. We now try to consider it as equal specially for > Methodref/Fieldref. ConstantPool merging is still really complicated and JVM_CONSTANT_Class/UnresolvedClass (and UnresolvedClassInError) may have changed to not track with what RedefineClasses does. If I'm reading this correctly, we are always calling find_matching_entry() and compare_entries_to() between the merged_cp and scratch_cp. Since we unresolve classes in merge_cp, and scratch_cp hasn't resolved anything yet, how are we getting this mismatch? Can you post a stack trace for us? ------------- PR Comment: https://git.openjdk.org/jdk/pull/14780#issuecomment-1629940553
