DROP_DEBUG and the constant pool

[Brian Goetz]

I'm going to object to the word "fix", because I'm not convinced 
something is broken here.  But we can think about the implications of 
this change (and in the meantime, you have an entirely suitable workaround.)

On 10/1/2025 9:12 AM, David Lloyd wrote:
> 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/1151a034/attachment.htm>