Generic type signatures in MethodRepository have many copies of simple class names

[Steven Schlansker]

> On Aug 10, 2025, at 2:29 PM, Johannes Döbler <jd at civilian-framework.org> wrote:
> 
> Hi Steven,
> 
> I think you are onto something. Given this example
> 
>> public class TypeParamsDemo {
>>     public static void main(String[] args) throws Exception {
>>         Method method = TypeParamsDemo.class.getMethod("getList", Set.class);
>>         TypeVariable<Method>[] tp = method.getTypeParameters();
>>     }
>> 
>>     public <T extends Number> List<T> getList(Set<T> set) {
>>         return new ArrayList<>(set);
>>     }
>> }
> 
> Then:
> tp[0].bounds[0].path[0].name is "java.lang.Number" and  is a newly created String parsed from the type signature "<T:Ljava/lang/Number;>(Ljava/util/Set<TT;>;)Ljava/util/List<TT;>;".
> The result of method.getTypeParameters() is cached in Method.genericInfo, so once initialized by a caller (e.g. by Jackson/REST easy) it won't go away.
> Imho interning the class name should be fine since it refers to an existing class.
> 
> Best
> Johannes
> 

Thank you for your analysis Johannes.
I've opened https://github.com/openjdk/jdk/pull/26730 with my proposed change.

> 
> On 09/08/2025 01:10, Steven Schlansker wrote:
>> Hello core-libs-dev, happy Friday!
>> 
>> While diagnosing an out of memory situation in our application, I noticed a surprising source of memory usage.
>> While this is not so severe to actually cause our OOM, it seems wasteful and I thought to bring it to your attention.
>> 
>> We use reflection-based technologies like Jackson JSON and RESTEasy that retrieve generic type information from many of our classes.
>> Our profiler provides diagnostics of wasted space due to duplicate objects, particularly Strings.
>> 
>> The analysis highlights many thousands of copies of String instances holding the full name of a class, e.g. "java.util.Optional"
>> or "com.mycompany.Id". The path to GC route looks like:
>> 
>> String <- sun.reflect.generics.tree.SimpleClassTypeSignature <- Object[] <- ArrayList <- ClassTypeSignature <- MethodTypeSignature <- MethodRepository <- Method
>> 
>> Seeing how these SimpleClassTypeSignature instances are created, it looks like they come from the sun.reflect.generics.parser.SignatureParser which calls
>> `input.substring(mark, index)`, possibly with a call to `replace('/', '.')` to munge the package name. In all but the simplest of cases, this will return a new String
>> for every call.
>> 
>> Since this String is representing a Class name, the cardinality should by its nature be very low. For each unique type, there will be many methods referring to it.
>> Additionally, this generic information is lazy-loaded at most once per Method object.
>> 
>> Therefore, SimpleClassTypeSignature.n seems like a natural place to apply String.intern(), for example changing:
>> 
>> public static SimpleClassTypeSignature make(String n,
>>     boolean dollar,
>>     TypeArgument[] tas){
>>         return new SimpleClassTypeSignature(n, dollar, tas);
>> }
>> 
>> to intern the name:
>> 
>> public static SimpleClassTypeSignature make(String n,
>>     boolean dollar,
>>     TypeArgument[] tas){
>>         return new SimpleClassTypeSignature(n.intern(), dollar, tas);
>> }
>> 
>> With any luck, maybe this can even share the same string instance as the class itself uses.
>> Am I correct in thinking this would be a moderately nice improvement, for a relatively cheap cost?
>> Or perhaps there's some reason this isn't a good idea?
>> 
>> Thank you for your thoughts on the subject,
>> Steven
>> 
>