As the maintainer of an "alternative" JavaVM I can confirm that we absolutely had to support library unloading because one customer was using it heavily - and that was quite a few years ago. Early Sun VMs didn't support library unloading, but then those VMs also did not garbage-collect obsolete classes either.
> On 21-11-2014 23:23, Viktor Dukhovni wrote: >> On Fri, Nov 21, 2014 at 04:13:58PM -0500, Jeffrey Walton wrote: >>>> A fixed amount of memory that is not deallocated and is independent >>>> of the number of operations performed, is NOT a memory leak. >>> Languages like Java and C# can continuously load and unload a library. >>> You will see a growth in memory usage because the memory is not >>> reclaimed. >> Unloading of shared libraries is generally unsafe. Loading and >> unloading of pure of Java packages may work well enough, but I >> would expect a Java runtime that unloads native libraries to stay >> running for very long. > > That is horribly outdated information and an assumption that no > competent library author should make or rely on others to make. > > On modern systems, unloading of shared libraries that are used > as plugins, and by extension any shared libraries that might be > referenced by plugins without being referenced by the plugin-using > application core, is a normal and frequent operation supported > by the core shared library loader and most shared libraries. > > If a library contains code that needs to be automatically called > when it is loaded or unloaded without that being an exposed API > level init/cleanup function, then the library porter needs to do > the target specific gymnastics to get called by the (C) runtime > at the appropriate times, and it needs to deal with common > restrictions on what such calls from the (C) runtime are not > allowed to do (one of which is recursive calls to the dynamic > loader API). For libraries written in C++, the static constructor > and destructor language mechanisms are treated this way > automatically and thus subject to the same limitations on > permitted operations. > > Enjoy > > Jakob > -- > Jakob Bohm, CIO, Partner, WiseMo A/S. http://www.wisemo.com > Transformervej 29, 2730 Herlev, Denmark. Direct +45 31 13 16 10 > This public discussion message is non-binding and may contain errors. > WiseMo - Remote Service Management for PCs, Phones and Embedded > ______________________________________________________________________ > OpenSSL Project http://www.openssl.org > User Support Mailing List openssl-users@openssl.org > Automated List Manager majord...@openssl.org > ______________________________________________________________________ OpenSSL Project http://www.openssl.org User Support Mailing List openssl-users@openssl.org Automated List Manager majord...@openssl.org
