Dynamic module loading

A Genero Business Development Language program is made of several 42m modules. Modules a linked together, or the dependency is defined with the IMPORT FGL instruction.

Except when using the debugger, modules are loaded dynamically when a module element (.i.e symbol) is required by the caller. For example, when executing a CALL instruction, the runtime system checks if the module of the function is already in memory. If not, the module is first loaded, then module variables are instantiated, and then the function is called.

Running programs are not affected by file replacements and will continue to run with an image of the module file that was originally loaded. However, replacing program modules during execution should be used with care: Since .42m modules are loaded dynamically on demand (when a symbol of the module is referenced), some modules may not yet be loaded, even if the program instance is already started. When replacing a module while programs are running, invalid symbol errors can occur if the module to be loaded does not correspond to the rest of the program modules that were loaded before the file replacements. See following scenario:

Program starts with V1 of main.42m, needing V1 of module libutil.42m (loaded later on demand).
Administrator upgrades application and installs main.42m and libutil.42m version V2.
Program running with V1 copy of main.42m calls a function from libutil.42m: runtime loads V2 of that module, while V1 is expected.

When live application updates are mandatory, consider installing new program and resource files (V2) in a different directory as the currently running version (V1), and use the FGLLDPATH and FGLRESOURCEPATH environment variables to point to the new files when starting a new (V2) program instance.

Note that on Windows™ platforms, program files currently in use cannot be overwritten, because of Windows OS memory mapping limitations. You need to turn off memory mapping with the FGLPROFILE entry fglrun.mmapDisable.