RFR: 8228604: StackMapFrames are missing from redefined class bytes of retransformed classes

[Alex Menkov]

On Tue, 24 Jan 2023 06:19:51 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> classFileParser drops stack map frames for JDK classes (when verification is not required).
>> As a result JvmtiClassFileReconstituter cannot restore the attribute for class redefinition.
>> Note that if the class is in CDS archive, the frames are restored from CDS, so this issue affects only JDK classes which are not in CDS.
>> This code is old (from "initial load") and I don't understand the reason it was implemented this way.
>> 
>> Testing: tier1-tier6
>
> Also AFAICS the issue reported here ie. the crashes, have been fixed since  JDK 12-b15, so I'm unclear why this change is proceeding?

@dholmes-ora thank you for the background.
I've read JSR-202 and re-read ASM and openjdk issues.

>From ASM report it seems to me that crashes mentioned occurred when ASM instrumented a class without StackMapTable and returned new class bytes from CFLH. And it looks like this is actually ASM issue (it generates bad classbytes with COMPUTE_MAX_STACK_AND_LOCAL_FROM_FRAMES when StackMapTable is absent).
Their reproducer does not cause the crash, it just checks if StackMapTable is present (and it checks only 2 classes: java.util.Date and java.text.SimpleDateFormat).
With my testing I saw that classes from CDS have StackMapTable, so my guess is Date and SimpleDateFormat classes were added to CDS in JDK 12-b15.

There are still some unclear points to me. Do we need verification for classes from CDS (I'm not familiar with the area)?
Also current JVM behavior looks inconsistent. I think it would be better to always restore the attributes (as the current fix does) or update fileReconstituter to never restore it.

-------------

PR: https://git.openjdk.org/jdk/pull/12155