problems with ldc on 24.36
Chen Liang
liangchenblue at gmail.com
Mon Feb 10 00:42:52 UTC 2025
Hello Mark,
This indeed is a bug; we can change this in 25 to make any entry with LDC
that has a pool entry with index over 0xFF throw IllegalArgumentException,
and add a new ofLoad and ofArgument factories that do not require the
Opcode (ClassFile API can choose a suitable opcode in these cases). We
anticipate users to call CodeBuilder.loadConstant(ConstantDesc) or
loadConstant(LoadableConstantEntry) so we did not enhance this more
complicated API.
This behavior exists so we allow specifying the Opcode, so that you can use
LDC_W for small index constants; before we automatically converted those
LDC_W to LDC even if the entry is from the same CP as the CodeBuilder; see
https://github.com/openjdk/jdk/blob/8f6ccde9829ea0e4fe1c087e68bec4d9efb55c64/src/java.base/share/classes/jdk/internal/classfile/impl/AbstractInstruction.java#L1352
A similar truncation issue was noted in
https://bugs.openjdk.org/browse/JDK-8341277 and fixed; but it didn't handle
CP indices, and this indeed is a good bug to fix for 25.
Regards, Chen
On Sun, Feb 9, 2025 at 6:22 PM Mark Roberts <markro at cs.washington.edu>
wrote:
> I just changed from 24-ea+22-2649 to 24+36-3646 and almost all my test
> cases worked fine. However, I ran into a problem with ldc:
>
>
>
> ConstantInstruction.ofLoad(Opcode.LDC,
> poolBuilder.stringEntry(binaryClassName))
>
>
>
> This used to work if the constant pool entry for binaryClassName was >256
> – it would automatically generate a ldc_w.
>
>
>
> Now it generates a ldc and uses just the lower 8 bits of the offset. This
> seems like a problem as a user is not expected to know the constant pool
> offset, are they?
>
>
>
> Thank you,
>
> Mark
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/classfile-api-dev/attachments/20250209/e5c12cf5/attachment-0001.htm>
More information about the classfile-api-dev
mailing list