On Thu, 6 Aug 2026 11:59:15 GMT, Coleen Phillimore <[email protected]> wrote:
>> 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. ??
>
> It is not why we kept the method Symbol around, that was for a special case
> and cost both footprint, gc time and performance. If the format of the name
> might be a problem, I could use redefineDeleted or something like that. I
> don't know why `<redefined deleted>` would be since the method name could
> also be `<init>`. I could also rename and use this symbol but it doesn't
> really describe why the method name can't be found.
>
> /* used by ClassFormatError when class name is not known yet */
> \
> template(unknown_class_name, "<Unknown>")
Now I remember, we used to return nullptr for name which caused some old tool
to crash, so we shouldn't return nullptr.
-------------
PR Review Comment: https://git.openjdk.org/jdk/pull/32202#discussion_r3728575862
