On Fri, 8 Apr 2022 06:52:57 GMT, Xue-Lei Andrew Fan <xue...@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
