DROP_DEBUG and the constant pool

[David Lloyd]

Then perhaps the cleaner fix is instead to have the default methods
delegate to `LocalVariable.of(int,String,ClassDesc,Label,Label)` directly?

On Wed, Oct 1, 2025 at 7:52 AM Brian Goetz <brian.goetz at oracle.com> wrote:

> 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
>
>
>

-- 
- DML • he/him
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/classfile-api-dev/attachments/20251001/cd760e93/attachment-0001.htm>