RFR: 8198540: Dynalink leaks memory when generating type converters [v7]
plevart at openjdk.java.net
Sun Jan 10 23:33:53 UTC 2021
On Sun, 10 Jan 2021 19:38:11 GMT, Attila Szegedi <attila at openjdk.org> wrote:
>> Hello Attila,
>> This looks good to me. Just a question: How frequent are situations where the two classloaders are unrelated?
>> 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.
Well, I was just thinking if it might be more frequent and would benefit from caching the result too. But if it is not, then what you have now is OK.
More information about the core-libs-dev