RFR: 8198540: Dynalink leaks memory when generating type converters [v7]
attila at openjdk.java.net
Sun Jan 10 19:40:57 UTC 2021
On Sun, 10 Jan 2021 17:18:37 GMT, Peter Levart <plevart at openjdk.org> wrote:
> How frequent are situations where the two classloaders are unrelated?
I think they'd be extremely unlikely. The only user of these right now is Dynalink's type converter factory. I _can imagine_ a situation where there's a conversion from a dynamic language runtime's internal "object" type to an application-specific Java interface, or from its internal "function object" type to an app-specific Java SAM type, and for some reason the app-specific types aren't in the same or descendant class loader of the language runtime's loader.
Frankly, I'd expect 99.99% of the time, app classes would be in the same-or-descendant class loader relative to the dynamic language runtime types. It'd have to be a really exotic setup for this not to be the case, but I'd rather not second guess the users and provide a reasonable functionality even in this case.
If you're thinking of rather throwing an exception when they're unrelated… well, we could certainly do that but I give it a mean time of six months before somebody runs into it and asks about it on Stack Overflow.
More information about the core-libs-dev