DROP_DEBUG and the constant pool

[David Lloyd]

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>