From david.lloyd at redhat.com  Wed Oct  1 12:31:18 2025
From: david.lloyd at redhat.com (David Lloyd)
Date: Wed, 1 Oct 2025 07:31:18 -0500
Subject: DROP_DEBUG and the constant pool
In-Reply-To: <SJ2PR10MB7669D176A1BFC7DE0D33BE6BA21AA@SJ2PR10MB7669.namprd10.prod.outlook.com>
References: <CANghgrR1Tzu5YZmy8KJDRd+kiPXHTks6ri7FfBR2mxoqgCiBkQ@mail.gmail.com>
 <SJ2PR10MB7669D176A1BFC7DE0D33BE6BA21AA@SJ2PR10MB7669.namprd10.prod.outlook.com>
Message-ID: <CANghgrTdgtqC9N1W763sxpTrxfSyi9dyn_Qn3uy=WSg_zUHvNQ@mail.gmail.com>

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>

From brian.goetz at oracle.com  Wed Oct  1 12:52:40 2025
From: brian.goetz at oracle.com (Brian Goetz)
Date: Wed, 1 Oct 2025 08:52:40 -0400
Subject: DROP_DEBUG and the constant pool
In-Reply-To: <CANghgrTdgtqC9N1W763sxpTrxfSyi9dyn_Qn3uy=WSg_zUHvNQ@mail.gmail.com>
References: <CANghgrR1Tzu5YZmy8KJDRd+kiPXHTks6ri7FfBR2mxoqgCiBkQ@mail.gmail.com>
 <SJ2PR10MB7669D176A1BFC7DE0D33BE6BA21AA@SJ2PR10MB7669.namprd10.prod.outlook.com>
 <CANghgrTdgtqC9N1W763sxpTrxfSyi9dyn_Qn3uy=WSg_zUHvNQ@mail.gmail.com>
Message-ID: <7105837a-dc37-41c6-851c-d20c7cc4c613@oracle.com>

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>

From david.lloyd at redhat.com  Wed Oct  1 13:12:37 2025
From: david.lloyd at redhat.com (David Lloyd)
Date: Wed, 1 Oct 2025 08:12:37 -0500
Subject: DROP_DEBUG and the constant pool
In-Reply-To: <7105837a-dc37-41c6-851c-d20c7cc4c613@oracle.com>
References: <CANghgrR1Tzu5YZmy8KJDRd+kiPXHTks6ri7FfBR2mxoqgCiBkQ@mail.gmail.com>
 <SJ2PR10MB7669D176A1BFC7DE0D33BE6BA21AA@SJ2PR10MB7669.namprd10.prod.outlook.com>
 <CANghgrTdgtqC9N1W763sxpTrxfSyi9dyn_Qn3uy=WSg_zUHvNQ@mail.gmail.com>
 <7105837a-dc37-41c6-851c-d20c7cc4c613@oracle.com>
Message-ID: <CANghgrR9A6zyOyM0FQPQgfTAw6Dwk1ywvjFU5FR10HTogNXpAw@mail.gmail.com>

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>

From brian.goetz at oracle.com  Wed Oct  1 13:16:49 2025
From: brian.goetz at oracle.com (Brian Goetz)
Date: Wed, 1 Oct 2025 09:16:49 -0400
Subject: DROP_DEBUG and the constant pool
In-Reply-To: <CANghgrR9A6zyOyM0FQPQgfTAw6Dwk1ywvjFU5FR10HTogNXpAw@mail.gmail.com>
References: <CANghgrR1Tzu5YZmy8KJDRd+kiPXHTks6ri7FfBR2mxoqgCiBkQ@mail.gmail.com>
 <SJ2PR10MB7669D176A1BFC7DE0D33BE6BA21AA@SJ2PR10MB7669.namprd10.prod.outlook.com>
 <CANghgrTdgtqC9N1W763sxpTrxfSyi9dyn_Qn3uy=WSg_zUHvNQ@mail.gmail.com>
 <7105837a-dc37-41c6-851c-d20c7cc4c613@oracle.com>
 <CANghgrR9A6zyOyM0FQPQgfTAw6Dwk1ywvjFU5FR10HTogNXpAw@mail.gmail.com>
Message-ID: <546a8d98-cd56-42ab-ae20-df9d455446e7@oracle.com>

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>

From david.lloyd at redhat.com  Wed Oct  1 13:28:30 2025
From: david.lloyd at redhat.com (David Lloyd)
Date: Wed, 1 Oct 2025 08:28:30 -0500
Subject: DROP_DEBUG and the constant pool
In-Reply-To: <546a8d98-cd56-42ab-ae20-df9d455446e7@oracle.com>
References: <CANghgrR1Tzu5YZmy8KJDRd+kiPXHTks6ri7FfBR2mxoqgCiBkQ@mail.gmail.com>
 <SJ2PR10MB7669D176A1BFC7DE0D33BE6BA21AA@SJ2PR10MB7669.namprd10.prod.outlook.com>
 <CANghgrTdgtqC9N1W763sxpTrxfSyi9dyn_Qn3uy=WSg_zUHvNQ@mail.gmail.com>
 <7105837a-dc37-41c6-851c-d20c7cc4c613@oracle.com>
 <CANghgrR9A6zyOyM0FQPQgfTAw6Dwk1ywvjFU5FR10HTogNXpAw@mail.gmail.com>
 <546a8d98-cd56-42ab-ae20-df9d455446e7@oracle.com>
Message-ID: <CANghgrTtcmc6pogJLJdbhExjMZJHODC=4NziMd2UeW_Kd44BeQ@mail.gmail.com>

OK, that's fair. But the sticking point to me is the documentation which
says: "This call may be ignored if ClassFile.DebugElementsOption.DROP_DEBUG
is set, or if any of the argument labels is not bound and
ClassFile.DeadLabelsOption.DROP_DEAD_LABELS is set." Granted "may" is a
wiggle word, but I think a reasonable reader would not interpret that as
the methods taking a partial effect as they do currently; rather that it
either is or is not ignored. So AFAICT *something* should be fixed, be it
the code or the documentation.

On Wed, Oct 1, 2025 at 8:18?AM Brian Goetz <brian.goetz at oracle.com> wrote:

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

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

From chen.l.liang at oracle.com  Wed Oct  1 14:18:03 2025
From: chen.l.liang at oracle.com (Chen Liang)
Date: Wed, 1 Oct 2025 14:18:03 +0000
Subject: [External] : Re: DROP_DEBUG and the constant pool
In-Reply-To: <CANghgrTtcmc6pogJLJdbhExjMZJHODC=4NziMd2UeW_Kd44BeQ@mail.gmail.com>
References: <CANghgrR1Tzu5YZmy8KJDRd+kiPXHTks6ri7FfBR2mxoqgCiBkQ@mail.gmail.com>
 <SJ2PR10MB7669D176A1BFC7DE0D33BE6BA21AA@SJ2PR10MB7669.namprd10.prod.outlook.com>
 <CANghgrTdgtqC9N1W763sxpTrxfSyi9dyn_Qn3uy=WSg_zUHvNQ@mail.gmail.com>
 <7105837a-dc37-41c6-851c-d20c7cc4c613@oracle.com>
 <CANghgrR9A6zyOyM0FQPQgfTAw6Dwk1ywvjFU5FR10HTogNXpAw@mail.gmail.com>
 <546a8d98-cd56-42ab-ae20-df9d455446e7@oracle.com>
 <CANghgrTtcmc6pogJLJdbhExjMZJHODC=4NziMd2UeW_Kd44BeQ@mail.gmail.com>
Message-ID: <SJ2PR10MB7669020789C0F9CBC4EDFE60A2E6A@SJ2PR10MB7669.namprd10.prod.outlook.com>

I considered this a bug because Class-File API intentionally prevents generating redundant CP entries elsewhere, such as in StackMapGenerator. (Using ClassDesc instead of ClassEntry for stack map type tracking)
I used "may" in the original spec because this is ignored for DirectCodeBuilder, but not ignored for Buffered/ChainedCodeBuilder used in transforms.
If we dig down the rabbit hole, we may argue that exceptionCatch is a candidate too - we might skip ones that are dead, but they already create CP entries.

As Brian said, there are workarounds - if you are transforming to drop debug elements, you should use a new constant pool to deduplicate. If you are building, you can skip the call yourself. I think the only scenario in which this matters is when you are transforming someone else's code as in CodeBuilder.transforming. What exactly is your use case that makes this problem apparent?

Chen
________________________________
From: David Lloyd <david.lloyd at redhat.com>
Sent: Wednesday, October 1, 2025 8:28 AM
To: Brian Goetz <brian.goetz at oracle.com>
Cc: Chen Liang <chen.l.liang at oracle.com>; classfile-api-dev at openjdk.org <classfile-api-dev at openjdk.org>; Ladislav Thon <lthon at redhat.com>
Subject: [External] : Re: DROP_DEBUG and the constant pool

OK, that's fair. But the sticking point to me is the documentation which says: "This call may be ignored if ClassFile.DebugElementsOption.DROP_DEBUG is set, or if any of the argument labels is not bound and ClassFile.DeadLabelsOption.DROP_DEAD_LABELS is set." Granted "may" is a wiggle word, but I think a reasonable reader would not interpret that as the methods taking a partial effect as they do currently; rather that it either is or is not ignored. So AFAICT *something* should be fixed, be it the code or the documentation.

On Wed, Oct 1, 2025 at 8:18?AM Brian Goetz <brian.goetz at oracle.com<mailto:brian.goetz at oracle.com>> wrote:
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<mailto: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<mailto: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<mailto:classfile-api-dev-retn at openjdk.org>> on behalf of David Lloyd <david.lloyd at redhat.com<mailto:david.lloyd at redhat.com>>
Sent: Tuesday, September 30, 2025 11:07 AM
To: classfile-api-dev at openjdk.org<mailto:classfile-api-dev at openjdk.org> <classfile-api-dev at openjdk.org<mailto:classfile-api-dev at openjdk.org>>
Cc: Ladislav Thon <lthon at redhat.com<mailto: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



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

From david.lloyd at redhat.com  Wed Oct  1 14:23:09 2025
From: david.lloyd at redhat.com (David Lloyd)
Date: Wed, 1 Oct 2025 09:23:09 -0500
Subject: [External] : Re: DROP_DEBUG and the constant pool
In-Reply-To: <SJ2PR10MB7669020789C0F9CBC4EDFE60A2E6A@SJ2PR10MB7669.namprd10.prod.outlook.com>
References: <CANghgrR1Tzu5YZmy8KJDRd+kiPXHTks6ri7FfBR2mxoqgCiBkQ@mail.gmail.com>
 <SJ2PR10MB7669D176A1BFC7DE0D33BE6BA21AA@SJ2PR10MB7669.namprd10.prod.outlook.com>
 <CANghgrTdgtqC9N1W763sxpTrxfSyi9dyn_Qn3uy=WSg_zUHvNQ@mail.gmail.com>
 <7105837a-dc37-41c6-851c-d20c7cc4c613@oracle.com>
 <CANghgrR9A6zyOyM0FQPQgfTAw6Dwk1ywvjFU5FR10HTogNXpAw@mail.gmail.com>
 <546a8d98-cd56-42ab-ae20-df9d455446e7@oracle.com>
 <CANghgrTtcmc6pogJLJdbhExjMZJHODC=4NziMd2UeW_Kd44BeQ@mail.gmail.com>
 <SJ2PR10MB7669020789C0F9CBC4EDFE60A2E6A@SJ2PR10MB7669.namprd10.prod.outlook.com>
Message-ID: <CANghgrSxDS+-H+d6Tf2meaVcAK_PBbhT-Kz0F5_hkkNEA3+dzA@mail.gmail.com>

We generate some fairly complex code, and we wanted to introduce a switch
to disable debug output. Setting this flag seemed like a simple
solution, but it didn't fully work out that way, which was unexpected. As
you and Brian have said, there are multiple possible workarounds, so we are
not stuck by any means.

On Wed, Oct 1, 2025 at 9:18?AM Chen Liang <chen.l.liang at oracle.com> wrote:

> I considered this a bug because Class-File API intentionally prevents
> generating redundant CP entries elsewhere, such as in StackMapGenerator.
> (Using ClassDesc instead of ClassEntry for stack map type tracking)
> I used "may" in the original spec because this is ignored for
> DirectCodeBuilder, but not ignored for Buffered/ChainedCodeBuilder used in
> transforms.
> If we dig down the rabbit hole, we may argue that exceptionCatch is a
> candidate too - we might skip ones that are dead, but they already create
> CP entries.
>
> As Brian said, there are workarounds - if you are transforming to drop
> debug elements, you should use a new constant pool to deduplicate. If you
> are building, you can skip the call yourself. I think the only scenario in
> which this matters is when you are transforming someone else's code as in
> CodeBuilder.transforming. What exactly is your use case that makes this
> problem apparent?
>
> Chen
> ------------------------------
> *From:* David Lloyd <david.lloyd at redhat.com>
> *Sent:* Wednesday, October 1, 2025 8:28 AM
> *To:* Brian Goetz <brian.goetz at oracle.com>
> *Cc:* Chen Liang <chen.l.liang at oracle.com>; classfile-api-dev at openjdk.org
> <classfile-api-dev at openjdk.org>; Ladislav Thon <lthon at redhat.com>
> *Subject:* [External] : Re: DROP_DEBUG and the constant pool
>
> OK, that's fair. But the sticking point to me is the documentation which
> says: "This call may be ignored if ClassFile.DebugElementsOption.DROP_DEBUG
> is set, or if any of the argument labels is not bound and
> ClassFile.DeadLabelsOption.DROP_DEAD_LABELS is set." Granted "may" is a
> wiggle word, but I think a reasonable reader would not interpret that as
> the methods taking a partial effect as they do currently; rather that it
> either is or is not ignored. So AFAICT *something* should be fixed, be it
> the code or the documentation.
>
> On Wed, Oct 1, 2025 at 8:18?AM Brian Goetz <brian.goetz at oracle.com> wrote:
>
> 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
>
>
>
>
> --
> - DML ? he/him
>


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