RFR: 8212136: Remove BaseSSLSocketImpl finalizer method [v2]

Bradford Wetmore wetmore at openjdk.java.net
Fri Apr 8 22:58:53 UTC 2022

On Fri, 8 Apr 2022 06:52:57 GMT, Xue-Lei Andrew Fan <xuelei at openjdk.org> wrote:

> The Socket implementation will take care of the file description/native memory release, I think.

I've walked through the network code and understand it now.  The Socket creation code calls into sun.nio.ch.NioSocketImpl.create():451, which then allocates the FileDescriptor fd and assigns it to the Socket, then registers a closer for that FileDescriptor which will be triggered by the Socket GC.  When the Socket is reclaimed, the FileDescriptor is released, but not by referencing the Socket itself.  

> It is expected to send the close_notify at the TLS layer. But the current code using finalizer, which is not reliable. The underlying socket may have been closed when the SSLSocket finalizing action is triggered. Generally, application should call close() method explicitly, otherwise the finalizer is not expect to work reliable. I was wondering it may be safe to remove the finalizer.

Yeah, I'm just not sure yet.  

> I agree that adding a best effort cleanup may be better. I was wondering to check if it is possible to clean the socket in the socket creation factories so that the object reference issues could be resolved. But as socket is a kind of resource, application layer may make the clean up as well.

> I'm still looking for a solution to clean up resource by using a method of 'this'. Please advice if anyone has experiences.

@AlanBateman, @dfuch, any great ideas here?


PR: https://git.openjdk.java.net/jdk/pull/8065

More information about the security-dev mailing list