JDK-8311879 : SA ClassWriter generates invalid invokedynamic code
  • Type: Bug
  • Component: hotspot
  • Sub-Component: svc-agent
  • Priority: P3
  • Status: Resolved
  • Resolution: Fixed
  • Submitted: 2023-07-11
  • Updated: 2023-07-25
  • Resolved: 2023-07-19
The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.
JDK 22
22 b07Fixed
Related Reports
Relates :  
JDK-8311103 - Enhancements and Fixes to SA ClassWriter
Relates :  
JDK-8294969 - Convert jdk.jdeps javap to use the Classfile API
Description
Invokedynamic instructions generated by the SA ClassWriter do not refer to valid constant pool entries.

More strict constant pool control in javap reveals that `serviceability/sa/ClhsdbDumpclass.java` test fails with errors (see attached log).
Comments
Changeset: aa23fd98 Author: Daohan Qu <dqu@openjdk.org> Committer: Chris Plummer <cjplummer@openjdk.org> Date: 2023-07-19 19:25:40 +0000 URL: https://git.openjdk.org/jdk/commit/aa23fd98f528069f5c613f43e335a0585a490176
19-07-2023
Yes, thank you, Ioi. I’ll update the PR name accordingly.
14-07-2023
I changed the name to "SA ClassWriter generates invalid invokedynamic code" since we have multiple ClassWriter.java in the JDK repo.
13-07-2023
Thanks for your information, Chris. An assertion like the following code snippet in `sun.jvm.hotspot.tools.jcore.ByteCodeRewriter` might also catch this. short cpIndex = (short) cpCache.getIndyEntryAt(cpCacheIndex).getConstantPoolIndex(); Assert.that(cpool.getTagAt(cpIndex).isInvokeDynamic(), "CP Entry should be InvokeDynamic"); You could refer to my PR above.
13-07-2023
Added noreg-other label since the issue is not reproducible until JDK-8294969 is pushed.
12-07-2023
A pull request was submitted for review. URL: https://git.openjdk.org/jdk/pull/14852 Date: 2023-07-12 13:49:17 +0000
12-07-2023
Hi Adam, I think it is a good catch because `javap` doesn't verify this! And the fix seems also to be straightforward. --- a/src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/tools/jcore/ByteCodeRewriter.java +++ b/src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/tools/jcore/ByteCodeRewriter.java @@ -102,7 +102,7 @@ public class ByteCodeRewriter // Invokedynamic require special handling cpCacheIndex = ~cpCacheIndex; cpCacheIndex = bytes.swapInt(cpCacheIndex); - return (short) cpCache.getEntryAt(cpCacheIndex).getConstantPoolIndex(); + return (short) cpCache.getIndyEntryAt(cpCacheIndex).getConstantPoolIndex(); } else if (fmt.contains("JJ")) { // change byte-ordering and go via cache return (short) cpCache.getEntryAt((int) (0xFFFF & bytes.swapShort((short)cpCacheIndex))).getConstantPoolIndex(); According to the code snippet in hotspot: https://github.com/openjdk/jdk/blob/753bd563ecca6bb5ff9b5ebc0957bc1854dce78d/src/hotspot/share/interpreter/rewriter.cpp#L291-L294
12-07-2023