On Wed, 5 Aug 2026 11:49:19 GMT, Coleen Phillimore <[email protected]> wrote:

>> This patch removes the work to save the Method name in the backtrace that 
>> was used for the case where redefinition could delete the method that was on 
>> the stack in the stack trace, but saved then deleted with redefinition 
>> later. RedefineClasses' ability to add/delete methods has been deprecated 
>> for many releases, so adding code and memory for this case is wasting space 
>> and time. This change speeds up Throwable microbenchmarks by about 10-30%, 
>> and speeds up DaCapo pmd by a bit.
>> 
>> Remerged with the change to factor out javaStackTraceClasses.
>> 
>> Tested with tier1-4.
>> 
>> ---------
>> - [x] I confirm that I make this contribution in accordance with the 
>> [OpenJDK Interim AI Policy](https://openjdk.org/legal/ai).
>
> Coleen Phillimore has updated the pull request incrementally with one 
> additional commit since the last revision:
> 
>   Remove spare file.

src/hotspot/share/classfile/javaStackTraceClasses.cpp line 378:

> 376: static inline Symbol* method_id_to_name_symbol(InstanceKlass* holder, 
> int method_id) {
> 377:   Method* method = holder->method_with_orig_idnum(method_id);
> 378:   return (method == nullptr) ? SymbolTable::new_symbol("<redefined 
> deleted>") : method->name();

I don't like creating symbols from arbitrary message strings like this. A 
Symbol for a method name should be guaranteed to meet all the naming rules for 
Java methods. This can make its way to Java code purporting to be a method name 
when in fact it is not. Perhaps this is in part why we go to all the trouble of 
keeping the old method name around. ??

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/32202#discussion_r3726260896

Reply via email to