Code segment unload

Code segment unload is a draft programming task. It is not yet considered ready to be promoted as a complete task, for reasons that should be found in its talk page.

Some advanced applications, such as memory resident applications, daemons and memory demanding applications unload unrequired parts of the application during use (such as initialization code that will no longer be used again once the application is operational) to free up memory and resources. Demonstrate or explain how to unload an unused section of code from memory.

Note that it is sufficient to flag the memory area as being available for reuse by the memory management system, without the need to demonstrate the zeroing of the bytes and performing a memory shuffle, unless such actions are required to free up the code segment.

Languages that do not have the facility to free up their code segment (such as scripting languages) can be omitted.

BASIC

Some versions of basic have the facility to delete lines of code: <lang gwbasic>10 GOSUB 5000: REM call initializer 20 DELETE 5000-9999: REM delete initializer 30 PRINT A: REM show initializer worked 40 LIST: REM show initializer has gone 50 END

5000 REM this is a dummy initializer 5010 LET A=1 5020 RETURN</lang>

COBOL

The CANCEL statement in COBOL unloads from memory the dynamically-loadable module containing the specified program or entry-point. <lang cobol>CANCEL "foo"</lang>

Io

<lang Io># Call anonymous block to do the initialization.

block(

   // Put initialization code here.        
   writeln("Initialization complete.")

) call()

1. Garbage collector is now free to recover initialization resources.

writeln("Doing real work.") // Code to do the real work here.</lang>

Output:

Initialization complete.
Doing real work.

Java

The situation for Java is as described below in the entry for its sister JVM language, Kotlin.

Kotlin

The principal version of Kotlin targets the JVM whose basic code unit is the 'class'. Each class has (and carries a reference to) a classloader which loads it into memory as needed. In most cases the classloaders are created automatically by the system. However, it is possible to create your own to enable classes to be loaded dynamically at runtime.

To my knowledge, there is no explicit mechanism for unloading a class. However, when there are no longer any references to any of its classes or a classloader itself, they will become eligible for garbage collection and the memory they were using will in due course be reclaimed by the garbage collector.

In most cases this is good enough as one of the tenets of the system is that the programmer is relieved from having to worry about memory management.

Even so, situations can arise where one would like a class to be unloaded as quickly as possible and a strategy for dealing with this is to create a classloader which will only load a single class (or a small number of classes) and to then carefully manage the creation of references so that you know when it is safe to unload it (or them). You can then request an immediate garbage collection by calling System.gc(). Note though that this is not guaranteed to work as the request may be overridden by the system if it is deemed to be inopportune.

PARI/GP

PARI code can be unloaded like any other C code. But if the code is in the form of a closure (i.e., a GEN object of type t_CLOSURE) then its space should be reclaimed by gerepile or moving ltop if it's at the bottom of the stack.

This is simpler in gp -- just kill the function (or set it to 0, not quite the same but will also cause the memory to be collected).

Perl 6

In general, there is no specific mechanism to do a timely destruction of an object, be it code, data, variables, whatever. Perl 6 does automatic garbage collection on objects that are no longer being used. Unlike previous version of Perl, Perl 6 doesn't use reference counting to track when memory may be garbage collected as that tends to be very difficult to get correct and performant in multi-threaded applications. Rather it performs a "reachability analysis" to determine when objects can be evicted from memory and safely removed.

Perl 6 objects can provide a "DESTROY" method, but you cannot be sure when (if ever) it will be called. Perl 6 tends to not be very memory frugal. If there is lots of memory to be had, it will cheerfully use lots of it. It gets more aggressive about conserving if memory is tight, but usually will trade memory for performance. If and when garbage collection has run, the freed memory is then available to to the general OS pool for any process to claim.

There are some specific details that will allow some finer control of garbage collection in special circumstances, but the average Perl 6 programmer will not need to know about or deal with them.

Python

The del statement can make objects (both code and data), available for reuse.

Scala

As the situation for Scala in a JVM concerned, the in the entry for its sister JVM language, #Kotlin applies too.

Racket

Racket has a JIT compiler that translates functions to machine code whenever they are applied. When such a function is garbage-collected, the JITted machine code is released or re-used with it. Therefore, to reclaim some executable code segment, simply drop references to the function.

REXX

When using REXX in the (VM) CMS environment, the use of   NUCXDROP   can be used to release memory (virtual storage) that a REXX program is using   (when previously loaded into virtual memory via   NUCXLOAD).

Tcl

Tcl can release memory associated with a program in three ways.

Releasing commands

The memory associated with a particular command can be released back to the general memory pool by deleting the command. This is done by either creating a new command with the same name, or by using rename to change the command's name to the empty string.

<lang tcl>rename exampleCmd ""</lang>

Releasing loaded extensions

The memory associated with a loaded extension can be released by using unload, provided the extension has registered a handler function (this is relatively uncommon). Once the handler function has run (which gives the extension an opportunity to destroy any commands and other callbacks it has created), the underlying library will be removed from memory with dlclose() (on Unix) or FreeLibrary() (on Windows). This completely removes the program code concerned, as well as returning the other ancillary memory to the general pool.

<lang tcl>unload theLibrary.dll</lang>

Releasing an entire interpreter

Provided an interpreter is not the root interpreter in its thread, you can delete it from an ancestor interpreter, which releases all the memory associated with it back into the general memory pool.

<lang tcl>interp delete theChildInterpreter</lang>