10.1. Overview

In K-3D, most functionality is implemented as plugins. Plugins are stored in shared libraries called modules, and dynamically loaded at runtime. Significant effort has been expended to develop the infrastructure to accomplish this. Modules are located and loaded at program startup time, so that the complete set of available plugins is always in memory and ready for use. As each module is loaded, it registers a set of plugin factories with the application. Each plugin factory can be queried for metadata describing the plugin type it represents, and is used to create instances of that plugin type. The set of available plugins and their capabilities is generated from the set of registered plugin factories. Great care has been taken to ensure that application code does not assume the availability of specific plugins or capabilities, and fails gracefully in their absence.

Although this system worked well for K-3D over many years, some drawbacks became obvious as the program grew. As plugin modules increased in size and number, application startup time increased. This was compounded by the growing number of plugin modules that had external dependencies on "third party" libraries. These dependencies were also loaded at startup, increasing the size of the application working-set and slowing startup further. The expanding set of runtime libraries became an even greater liability during debugging, when the debugger must load both dependent libraries and their debugging symbols before debugging can start. These issues finally reached a point where a system with 512Mb real and 512Mb virtual memory could not load a K-3D core dump into gdb.