DROP_DEBUG and the constant pool

[Brian Goetz]

After thinking about it for a few more minutes, I'm less sure of this 
approach (and not sure I'd even classify it as a bug.)  While locally 
this change is probably harmless, there are dozens of uses of the idiom 
`constantPool().xxxEntry()` in this class -- why would we switch just 
some of them over to using the temp pool?  And switching all of them 
over falls into a more significant change in implementation approach, 
for which the bar is surely higher.

In any case, I think we don't need to change anything; the code you want 
is already in the library.  Just do

     builder.with(LocalVariable.of(slot, name, desc, start, end))

since that's exactly what LocalVariable::of does:

     static LocalVariable of(int slot,String name,ClassDesc descriptor,Label startScope,Label endScope) {
         return of(slot,
                   TemporaryConstantPool.INSTANCE.utf8Entry(name),
                   TemporaryConstantPool.INSTANCE.utf8Entry(descriptor.descriptorString()),
                   startScope,endScope);
     }
}









On 10/1/2025 8:31 AM, David Lloyd wrote:
> OK, shall I prepare a bug report and patch? Thanks.
>
> On Tue, Sep 30, 2025 at 2:55 PM Chen Liang <chen.l.liang at oracle.com> 
> wrote:
>
>     Hi David, this seems a legitimate bug.
>
>     I think we can bypass this by using the
>     TemporaryConstantPool.INSTANCE to construct the UTF-8 entries.
>
>     Regards, Chen
>     ------------------------------------------------------------------------
>     *From:* classfile-api-dev <classfile-api-dev-retn at openjdk.org> on
>     behalf of David Lloyd <david.lloyd at redhat.com>
>     *Sent:* Tuesday, September 30, 2025 11:07 AM
>     *To:* classfile-api-dev at openjdk.org <classfile-api-dev at openjdk.org>
>     *Cc:* Ladislav Thon <lthon at redhat.com>
>     *Subject:* DROP_DEBUG and the constant pool
>     We've observed that when using `DROP_DEBUG` in conjunction with
>     `CodeBuilder#localVariable` and/or `localVariableType`, some
>     (otherwise useless) constant pool entries are still being created
>     (which contain, I believe, both the variable name and descriptor).
>     This was observed using a backport of the JDK classfile API based
>     on JDK 25.
>
>     Would this be expected behavior? Is there a separate step needed
>     to clean the constant pool for cases like this?
>
>     It looks to me to be the consequence of how the default methods
>     for local variable creation are implemented, e.g.:
>
>       default CodeBuilder localVariable(int slot, String name,
>     ClassDesc descriptor, Label startScope, Label endScope) {
>             return localVariable(slot,
>      constantPool().utf8Entry(name),
>      constantPool().utf8Entry(descriptor),
>                                  startScope, endScope);
>         }
>
>     The constant pool is accessed even when `DROP_DEBUG` is enabled,
>     because that flag is used later on in the process, and it seems
>     that these entries are never dropped, even if they are unused.
>
>     -- 
>     - DML • he/him
>
>
>
> -- 
> - DML • he/him
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/classfile-api-dev/attachments/20251001/5c686123/attachment.htm>