Met lots of class loading/unloading when using default methods

[kojilin]

What kind of issue is this?

• Feature Request. Start by telling us what problem you’re trying to solve. Often a solution
  already exists! Don’t send pull requests to implement new features without first getting our
  support. Sometimes we leave features out on purpose to keep the project small.

We are using default method to omit some default parameters, but we met lots of class loading/unloading in our environment(1.8.0_121, G1GC). Looks like after each young gc will make it recreate LambdaForm$BMH or LambdaForm$DMH in next request. I enabled -XX:+TraceClassLoading and -XX:+TraceClassUnloading.

[Unloading class java.lang.invoke.LambdaForm$BMH/2110450308 0x00000007c1746c28]
[Unloading class java.lang.invoke.LambdaForm$BMH/1598730347 0x00000007c1746828]
[Unloading class java.lang.invoke.LambdaForm$BMH/1380181431 0x00000007c1746428]
[Unloading class java.lang.invoke.LambdaForm$BMH/1090809169 0x00000007c1746028]
[Unloading class java.lang.invoke.LambdaForm$BMH/1828313973 0x00000007c1745c28]
[Unloading class java.lang.invoke.LambdaForm$DMH/1545216975 0x00000007c1745828]
[Unloading class java.lang.invoke.LambdaForm$DMH/829703186 0x00000007c1745428]
...

Maybe it needs to cache like serviceMethodCache?

--

Update with test case(Test in jdk1.8.0_162):
https://gist.github.com/kojilin/cd13940f2f8b2a06220b20efe7eab264
run with -XX:+TraceClassLoading -XX:+TraceClassUnloading

• unloadingCase will have many [Loaded java.lang.invoke.LambdaForm$DMH/
  and if we force it to run GC, it will have lots of [Unloading class java.lang.invoke.LambdaForm$BMH.
• safeCase won't have that problem.

[artem-zinnatullin]

Class unloading is up to JVM and GC implementation and runtime conditions.

Do you see this happening even when you are far from Xmx value and there is no memory pressure?

It would be strange if every library would need to implement own class caching (through reflection…) just because users can use default methods in interfaces :)

[kojilin]

Thanks, also I found I can't reproduce in my test case. I will check if there is something wrong in my environment again.

[kojilin]

Just found the case to test.
run with -XX:+TraceClassLoading -XX:+TraceClassUnloading
example: https://gist.github.com/kojilin/cd13940f2f8b2a06220b20efe7eab264
unloadingCase will have many [Loaded java.lang.invoke.LambdaForm$DMH/
and if we force it to run GC, it will have lots of [Unloading class java.lang.invoke.LambdaForm$BMH.

safeCase won't have that problem. The difference is one of it is using primitive type or not.
And looks like DirectMethodHandle.java fallback MethodType to (Object)Object, and it keeps exists in cache.
http://grepcode.com/file/repository.grepcode.com/java/root/jdk/openjdk/8-b132/java/lang/invoke/DirectMethodHandle.java#194
and
http://grepcode.com/file/repository.grepcode.com/java/root/jdk/openjdk/8-b132/java/lang/invoke/MethodType.java?av=f#301

But primitive's one still keep as (double)Object and cleared after GC.
So next time when we call it, it need to rebuild LambdaForm and reload class at
http://grepcode.com/file/repository.grepcode.com/java/root/jdk/openjdk/8-b132/java/lang/invoke/DirectMethodHandle.java#280