-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Mark,
On 10/26/17 4:55 PM, Mark Thomas wrote: > On 26/10/17 20:17, Christopher Schultz wrote: > > <snip/> > >> So this is relying on the OpenSSLContext.finalize() method to >> clean-up after the native SSL context? > > Correct. > >> It's been "recommended" to not rely on finalizers for quite a >> long time. Is that advice no longer correct? > > Like most general rules there are exceptions. Arguably, this is one > of them. The alternative would require an awful lot of code to > replicate what the JVM is already doing. Yes. When we spoke in person, we were both a little concerned about doing things like reference-counting to make sure that long-lived connections such as Websockets didn't get cut-off at the knees while also avoiding memory leaks. I think use of a finalizer is the correct solution. > I believe there are better options available in Java 9. Such as? I haven't looked at Java 9 very closely at all. >> I'm particularly concerned about native memory leaks. > > The argument against finalizers is that they might never run as the > JVM could shutdown before they are called. In this case, that > doesn't present a problem. +1 > We'd have a problem if an object could be GC'd without the > finializer running. I'm not aware of any scenarios where that > happens. Okay, good. My biggest concern is that the GC will take the laziest route and simply NEVER call the finalizer -- and also not GC the object. I can't imagine how the GC could know which objects might be "complicated" to finalize and for some reason decide to just stuff them in the closet forever. I just wanted to bring up the subject to make sure it was a deliberate decision. Thanks for clarifying. - -chris -----BEGIN PGP SIGNATURE----- Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAln3NmMACgkQHPApP6U8 pFiB4A//a3rDY2ZV3iJHIvWb/DdrI5riqAO12bZWkNbF3e7FDSxrXx/0X8/+pu3O 9laCZzVyFeRUdzIXXbtRVaI2gf8a1ZMve9UagciFwhkO0Z4IdzvXhEFDTyjmRo1c bVlgdGFWEHzs+b/snM/H8y4Ak1J3Psr3UNz6GeZjH93cogJ9OWUouqRLYpWzPdtW XHqXAg/p3H15FVc1Anwre8h2jVcDFy9G2d0dBODnq/oTHCYaErDQ6cS//jUfPlNZ L848Tp0lB+FZQcSdraQsjATdP/gPpsgmbHbS1r39wOjAf7VSZdLlZFXvDuv0KB2l rkQJ/C5sO1mHwSQNghcNDjLoCZ6mjPQMtfHLNy2Q/CY3dFt8YAt4f/ITY/H2f7Kd kmUPAyyGDDpDQenjAZQQ+C60NqqEa6JPTUn5n2+a9520VKviWaWvupjUn3u7XRot eQu614ikiR09M4diLvslkCH/0bBqgagdNJ70D2qqCT2F2IUGCZlDz+LaJokkwF3m jaw+WhVRQs+PkWHTYYecYrTCbS6kxQZJsyPjUNPeChxNccVI+s2K7BRsvGiQz/Pa TujcguxY3+6rphEGp49edZqIFoUb/90NxCXZZpC7PEUnyy67dut4PUUqpie2LOfD hnha9vUHj2DG74JljZghHWV5W5Un5fDbPfBSnt5h5JVJzqHBvIM= =R0Ch -----END PGP SIGNATURE----- --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
