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