On Tue, 24 Jan 2023 06:19:51 GMT, David Holmes <dhol...@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
