DROP_DEBUG and the constant pool

[David Lloyd]

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/297a4121/attachment-0001.htm>