RFR: 8223260: NamingManager should cache InitialContextFactory
Seán Coffey
sean.coffey at oracle.com
Thu Feb 6 15:32:48 UTC 2020
On 05/02/20 16:51, Daniel Fuchs wrote:
> On 05/02/2020 15:31, Peter Levart wrote:
>>> I think this is about allow the InitialContextFactory instance to be
>>> GC'ed when the thread is long lived. It might not be a concern for
>>> the LDAP or the other providers in the JDK.
>>>
>>> -Alan
>>
>> Ah, I see. You mean when the ClassLoader is long lived. So this is a
>> normal matter of trying to release the InitialContextFactory and
>> objects held by it when there is a memory pressure and not the matter
>> of avoiding class loader leaks? In this case it would pay only if
>> InitialContextFactory holds more memory than SoftReference itself...
>>
>> Regards, Peter
>
> Hi Peter,
>
> Yes the concern is that the InitialContextFactory would be kept around
> until the ClassLoader itself is GC'ed, even if the factory was used once
> and not needed anymore. Could that become an issue in case the factory
> is loaded e.g. by the System ClassLoader?
> But it's a good point that it might not be a concern if the
> InitialContextFactory instance in itself doesn't retain much memory.
InitialContextFactory itself is an extremely simple interface with one
method. I've browsed some code bases and could only find a small number
of such Factories implementations with simple logic to return a Context.
Applications will most likely delegate to the same Factory over and over
also (albeit, it's all controlled by HashTable parameters). The new
caching logic should help memory pressure here and not hinder it. I'm
not seeing a major concern with current solution as a result.
regards,
Sean.
>
> best regards,
>
> -- daniel
More information about the core-libs-dev
mailing list