Code segment unload: Difference between revisions
Added FreeBASIC
Thundergnat (talk | contribs) (→{{header|Perl 6}}: Add verbiage about Perl 6) |
(Added FreeBASIC) |
||
| (13 intermediate revisions by 9 users not shown) | |||
Line 8:
=={{header|BASIC}}==
Some versions of basic have the facility to delete lines of code:
<
20 DELETE 5000-9999: REM delete initializer
30 PRINT A: REM show initializer worked
Line 16:
5000 REM this is a dummy initializer
5010 LET A=1
5020 RETURN</
=={{header|COBOL}}==
The <code>CANCEL</code> statement in COBOL unloads from memory the dynamically-loadable module containing the specified program or entry-point.
<
In FreeBASIC, there is no direct way to unload an unused section of code from memory. However, you can free memory used by variables or data.
Here's an example of how you could do it:
<syntaxhighlight lang="vbnet">DIM AS INTEGER PTR p
p = CALLOC(100, SIZEOF(INTEGER)) ' Reserve memory for 100 integers
'Use memory...
DEALLOC(p) ' Free the memory
p = NULL ' Ensures that the pointer does not point to a freed memory location
</syntaxhighlight>
=={{header|Furor}}==
The <code>neglect</code> statement in Furor deletes from memory the named function. It is possible because each function is loaded into a dinamycally allocated memory segment.
<syntaxhighlight lang="Furor">foo neglect</syntaxhighlight>
=={{header|Go}}==
Although Go supports plug-ins, it is not currently possible to unload them once they have been loaded. This is likely to remain the case as runtime considerations (e.g. stopping goroutines, leaving dangling references) might make it unreliable to do so. However, any objects which the plug-in code creates on the heap will of course be garbage collected when there are no longer any references to them.
In practice, if a Go executable were required to run in a memory-constrained environment, the only option would be to try and divide the executable into a chain of smaller executables which would call the next one in the chain (possibly passing it some parameters) before exiting. Such chaining can be achieved using functions in the os/exec package of the standard library.
=={{header|Io}}==
<
block(
Line 33 ⟶ 56:
writeln("Doing real work.")
// Code to do the real work here.</
{{output}}
Line 41 ⟶ 64:
=={{header|Java}}==
The situation for Java is as described below in the entry for its sister JVM language, Kotlin.
=={{header|Julia}}==
Julia's functions are compiled and their code allocated memory "just in time" the first time their
code is run. Usually, memory used within a function can be dynamically garbage collected once that
data is out of scope. To also garbage collect the memory used by a function's code, it would be
necessary to define and run a new function with the same name and argument types, which would allow
the prior function's code memory to be reclaimed. In practice, this is seldom needed or done,
since most memory usage in Julia is for data, not code.
=={{header|Kotlin}}==
Line 57 ⟶ 88:
This is simpler in gp -- just <code>kill</code> the function (or set it to 0, not quite the same but will also cause the memory to be collected).
=={{header|Perl
Perl uses reference counting as its method of managing memory use. As soon as the last reference to a value is released, the value may be destroyed and freed, and handed back to the memory pool. However the exact timing of this action is not under programmer control.
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. ▼
Within your program, by using <code>undef</code> and <code>delete</code>, you can <i>hint</i> to Perl that it would now be OK to release this memory. Most importantly, such actions should not be confused with releasing memory back to the operating system. In cases where it is necessary to temporarily allocate a large amount of memory, do so via <code>fork</code>, so when the child process exits the memory is truly freed back to the system.
=={{header|Phix}}==
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. ▼
For compiled programs there is little you could do to reclaim the space of code segments as written to the PE/ELF executable,
other than to perhaps "daisy-chain" executables. You could wrap FreeLibrary/dlcose as per OpenOneDLL() in builtins/VM/pcfunc.e.
For interpreted programs however, the code is built and executed in dynamically allocated memory, and in fact "p -test" runs some 60 separate test programs, some of which are deliberately memory-intensive. For each one it allocates a full execution environment, including code space, a call stack, and new heap, and tears it all down and reclaims the memory on completion. That process is, fairly obviously, quite involved and not for the faint hearted, but clearly doable.
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.▼
=={{header|Python}}==
The [https://docs.python.org/3.4/reference/simple_stmts.html?highlight=del#grammar-token-del_stmt del] statement can make objects (both code and data), available for reuse.
▲=={{header|Scala}}==
As the situation for Scala in a JVM concerned, the in the entry for its sister JVM language, [[#Kotlin]] applies too.▼
=={{header|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.
=={{header|Raku}}==
(formerly Perl 6)
▲In general, there is no specific mechanism to do a timely destruction of an object, be it code, data, variables, whatever.
▲
▲There are some specific details that will allow some finer control of garbage collection in special circumstances, but the average
=={{header|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''').<br><br>
=={{header|Scala}}==
▲As the situation for Scala in a JVM concerned, the in the entry for its sister JVM language, [[#Kotlin]] applies too.
=={{header|Smalltalk}}==
Smalltalk runs in an image that can be saved to disk as a snapshot, and later loaded into memory and resumed. The VM (there are multiple implementations) performs garbage collection on this image, and usually also compacts it so that un-needed memory can be returned to the OS. The snapshot-resume cycle might do other kinds of compaction that reduces the image size even further.
The different phases of the GC can be explicitly invoced to ''reclaim'' unused memory immediately, but it does not guarantee the reclaimed memory is deemed excessive and therefore will be returned to the OS.
=={{header|Tcl}}==
Line 76 ⟶ 127:
;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 <code>rename</code> to change the command's name to the empty string.
:<
;Releasing loaded extensions
:The memory associated with a loaded extension can be released by using <code>unload</code>, 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 <code>dlclose()</code> (on Unix) or <code>FreeLibrary()</code> (on Windows). This ''completely'' removes the program code concerned, as well as returning the other ancillary memory to the general pool.
:<syntaxhighlight 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.
:<syntaxhighlight lang
=={{header|Wren}}==
It is not currently possible to unload code from a running Wren script.
However, what you can do is to place code that will only be run once, such as initialization code, into a function and then call that. Functions (as opposed to class methods) are first class objects in Wren and will be garbage collected when there are no longer any references to them. This doesn't usually occur immediately but you can request an immediate collection by calling the ''System.gc'' method.
{{omit from|360 Assembly|Depends entirely on the hardware implementation}}
{{omit from|6502 Assembly|Depends entirely on the hardware implementation}}
{{omit from|6800 Assembly|Depends entirely on the hardware implementation}}
{{omit from|68000 Assembly|Depends entirely on the hardware implementation}}
{{omit from|8051 Assembly|Depends entirely on the hardware implementation}}
{{omit from|8080 Assembly|Depends entirely on the hardware implementation}}
{{omit from|8086 Assembly|Depends entirely on the hardware implementation}}
{{omit from|AArch64 Assembly|Depends entirely on the hardware implementation}}
{{omit from|ARM Assembly|Depends entirely on the hardware implementation}}
{{omit from|AWK}}
{{omit from|Brlcad}}
{{omit from|GUISS}}
{{omit from|Lilypond}}
{{omit from|Logtalk}}
{{omit from|Mathematica}}
{{omit from|MIPS Assembly|Depends entirely on the hardware implementation}}
{{omit from|MIRC Scripting Language}}
{{omit from|TPP}}
{{omit from|UNIX Shell}}
{{omit from|VAX Assembly|Depends entirely on the hardware implementation}}
{{omit from|X86 Assembly|Depends entirely on the hardware implementation}}
{{omit from|Z80 Assembly|Depends entirely on the hardware implementation}}
{{omit from|ZX Spectrum Basic}}
| |||