From david.lloyd at redhat.com  Tue Sep 30 16:07:03 2025
From: david.lloyd at redhat.com (David Lloyd)
Date: Tue, 30 Sep 2025 11:07:03 -0500
Subject: DROP_DEBUG and the constant pool
Message-ID: <CANghgrR1Tzu5YZmy8KJDRd+kiPXHTks6ri7FfBR2mxoqgCiBkQ@mail.gmail.com>

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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/classfile-api-dev/attachments/20250930/e8dcec80/attachment.htm>

From chen.l.liang at oracle.com  Tue Sep 30 19:55:18 2025
From: chen.l.liang at oracle.com (Chen Liang)
Date: Tue, 30 Sep 2025 19:55:18 +0000
Subject: DROP_DEBUG and the constant pool
In-Reply-To: <CANghgrR1Tzu5YZmy8KJDRd+kiPXHTks6ri7FfBR2mxoqgCiBkQ@mail.gmail.com>
References: <CANghgrR1Tzu5YZmy8KJDRd+kiPXHTks6ri7FfBR2mxoqgCiBkQ@mail.gmail.com>
Message-ID: <SJ2PR10MB7669D176A1BFC7DE0D33BE6BA21AA@SJ2PR10MB7669.namprd10.prod.outlook.com>

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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/classfile-api-dev/attachments/20250930/c24038b9/attachment.htm>