Memory allocation: Difference between revisions

 

=={{header|360 Assembly}}==

* Request to Get Storage Managed by "GETMAIN" Supervisor Call (SVC 4)

LA 1,PLIST Point Reg 1 to GETMAIN/FREEMAIN Parm List

DC A(STG@) Pointer to Address of Storage Area

DC X'0000' (Unconditional Request; Subpool 0)

 

Example below shows de facto modern day use of HLASM techniques:

* The code shows the use of the system supplied linkage stack to save caller's registers (BAKR) and restore them on return (PR), as opposed to STM/LM of the caller's register contents.

* Finally, the code is REENTRANT, meaning it could be loaded in a system module directory (LINKLIST, LPA), and executed simultaneously by multiple callers. Though not a requirement for this type of sample code it is a best practice in assembler coding.

STOREXNO AMODE 31

STOREXNO RMODE ANY

WALEN EQU *-DYNAREA length of obtained area

END STOREXNO end of module

 

=={{header|6502 Assembly}}==

 

The "heap" can be considered the zero page, or any other section of RAM that the hardware allows for general access. Anything besides the zero page is platform-specific. Accessing the heap is as simple as storing values in a specified address.

STA $00 ;store at zero page memory address $00

 

A byte can be stored to the stack with <code>PHA</code> and retrieved with <code>PLA</code>. Later revisions of the 6502 allowed the X and Y registers to be directly pushed/popped with <code>PHX</code>, <code>PHY</code>, <code>PLX</code>, and <code>PLY</code>. The original 6502 could only access the stack through the accumulator.

 

=={{header|Ada}}==

===Stack===

[[Stack]] in [[Ada]] is allocated by declaration of an object in some scope of a block or else a subprogram:

X : Integer; -- Allocated on the stack

begin

...

===Heap===

[[Heap]] is allocated with the allocator '''new''' on the context where a pool-unspecific pointer is expected:

type Integer_Ptr is access Integer;

Ptr : Integer_Ptr := new Integer; -- Allocated in the heap

begin

...

The memory allocated by '''new''' is freed when:

* the type of the pointer leaves the scope;

* the memory pool is finalized

* an instance of Ada.Unchecked_Deallocation is explicitly called on the pointer

type Integer_Ptr is access Integer;

procedure Free is new Ada.Unchecked_Deallocation (Integer, Integer_Ptr)

Free (Ptr); -- Explicit deallocation

...

===User pool===

The allocator '''new''' also allocates memory in the user-defined storage pool when the pointer bound to the pool.

===Implicit allocation===

Elaboration of compilation units may result in allocation of the objects declared in these units. For example:

X : Integer; -- Allocated in the result the package elaboration

The memory required by the object may be allocated statically or dynamically depending on the time of elaboration and its context. Objects declared in the library level packages are equivalent to what in some languages is called ''static'' object.

 

{{works with|ELLA ALGOL 68|Any (with appropriate job cards) - tested with release [http://sourceforge.net/projects/algol68/files/algol68toc/algol68toc-1.8.8d/algol68toc-1.8-8d.fc9.i386.rpm/download 1.8-8d]}}

Given:

===Stack===

===Heap===

===User pool===

INT new pool := LWB pool-1;

===External memory===

Without extensions it is not possible to access external memory. However most implementations have such an extension!

===Implicit allocation===

 

=={{header|ALGOL W}}==

Algol W has garbage collected dynamic allocation for record structures.

% define a record structure - instances must be created dynamically %

record Element ( integer atomicNumber; string(16) name );

X := Element( 2, "Helium" )

% the memory allocated will now be garbage collected - there is no explicit de-allocation %

 

=={{header|AutoHotkey}}==

 

=={{header|Axe}}==

Axe does not provide runtime support for a heap, so memory must be allocated statically.

 

The optional second parameter to Buff() allows you to specify the byte to be filled with (default is zero).

 

DIM mem% size%-1

Memory allocated from the heap is only freed on program termination or CLEAR.

PROCstack(size%)

END

DIM mem% LOCAL s%-1

PRINT ; s% " bytes of stack allocated at " ; mem%

Memory allocated from the stack is freed on exit from the FN or PROC.

 

 

The Bracmat functions <code>alc$</code> and <code>fre$</code> call the C-functions <code>malloc()</code> and <code>free()</code>, respectively. Writing and reading to and from allocated memory is done with the poke and peek functions <code>pok$</code> and <code>pee$</code>. These funtions write and read in chunks of 1 (default), 2 or 4 bytes. No need to say that all these low-level functions easily can create havoc and should be disabled in serious applications that don't need them. (There are compiler preprocessor macros to do that.)

& pok$(!p,123456789,4) { poke a large value as a 4 byte integer }

& pok$(!p+4,0,4) { poke zeros in the next 4 bytes }

& out$(pee$(!p+1000,2)) { peek some uninitialized data }

& fre$!p { free the memory }

{{out}}

<pre>21

The functions <tt>malloc</tt>, <tt>calloc</tt> and <tt>realloc</tt> take memory from the heap. This memory ''should'' be released with <tt>free</tt> and it's suitable for sharing memory among threads.

 

 

/* size of "members", in bytes */

free(ints); free(int2);

return 0;

 

Variables declared inside a block (a function or inside a function) take room from the stack and survive until the "block" is in execution (and their scope is local).

 

{

int ints[NMEMB]; /* it resembles malloc ... */

 

return 0;

 

{{works with|gcc}}

The libc provided by [[gcc]] (and present on other "systems" too) has the <tt>alloca</tt> function which allows to ask for memory on the stack explicitly; the memory is deallocated when the function that asked for the memory ends (it is, in practice, the same behaviour for automatic variables). The usage is the same as for functions like <tt>malloc</tt>

 

int *funcA()

{

return ints; /* BUT THIS IS WRONG! It is not like malloc: the memory

does not "survive"! */

 

Variables declared outside any block and function or inside a function but prepended with the attribute <tt>static</tt> live as long as the program lives and the memory for them is statically given (e.g. through a .bss block).

 

int integers[NMEMB]; /* should be initialized with 0s */

 

{

integers[0] = a;

 

=={{header|C sharp|C#}}==

C# is a managed language, so memory allocation is usually not done manually. However, in unsafe code it is possible to declare and operate on pointers.

using System.Runtime.InteropServices;

 

static extern int HeapSize(int hHeap, int flags, void* block);

 

 

=={{header|C++}}==

While the C allocation functions are also available in C++, their use is discouraged. Instead, C++ provides <code>new</code> and <code>delete</code> for memory allocation and deallocation. Those function don't just allocate memory, but also initialize objects. Also, deallocation is coupled with destruction.

 

int main()

p2 = new std::string[10]; // allocate an array of 10 strings, default-initialized

delete[] p2; // deallocate it

Note that memory allocated with C allocation functions (<code>malloc</code>, <code>calloc</code>, <code>realloc</code>) must always be deallocated with <code>free</code>, memory allocated with non-array <code>new</code> must always be deallocated with <code>delete</code>, and memory allocated with array <code>new</code> must always deallocated with <code>delete[]</code>. Memory allocated with new also cannot be resized with <code>realloc</code>.

 

 

Besides the new expressions shown above, pure memory allocation/deallocation without object initialization/destruction can also be done through <code>operator new</code>:

{

void* memory = operator new(20); // allocate 20 bytes of memory

operator delete(memory); // deallocate it

 

There's also a placement form of new, which allows to construct objects at an arbitrary adress (provided it is correctly aligned, and there's enough memory):

 

int main()

int* p = new(&data) int(3); // construct an int at the beginning of data

new(p+1) int(5); // construct another int directly following

Indeed, code like <code>int* p = new int(3);</code> is roughly (but not exactly) equivalent to the following sequence:

 

Normally, new throws an exception if the allocation fails. there's a non-throwing variant which returns a null pointer instead:

 

Note that the nothrow variant does <em>not</em> prevent any exceptions to be thrown from the constructor of an object created with new. It only prevents exceptions due to memory allocation failure.

 

It is also possible to implement user-defined variations of operator new. One possibility is to define class-based operator new/operator delete:

#include <cstdlib>

#include <new>

int* p2 = new int; // uses default operator new

delete p2; // uses default operator delete

 

Another possibility is to define new arguments for placement new syntax, e.g.

 

void* operator new(std::size_t size, arena& a)

arena whatever(/* ... */);

 

Note that there is ''no'' placement delete syntax; the placement operator delete is invoked by the compiler only in case the constructor of the newed object throws. Therefore for placement newed object deletion the two steps must be done explicitly:

 

int main()

p->~MyClass(); // explicitly destruct *p

operator delete(p, whatever); // explicitly deallocate the memory

 

=={{header|COBOL}}==

 

Manual memory allocation is primarily done using <code>ALLOCATE</code> and <code>FREE</code>. They are used with data items with a <code>BASED</code> clause, which indicates that the data will be allocated at runtime. A <code>BASED</code> data item cannot be used before it has been allocated or after it has been freed. Example usage:

 

DATA DIVISION.

 

GOBACK

 

{{out}}

This behavior can be observed with the (not good for actual use) code:

 

(let ((a (cons 1 2))

(b (cons 1 2)))

(declare (dynamic-extent b))

 

produces

<pre>

 

=={{header|D}}==

// D supports thread-local memory on default, global memory, memory

// allocated on the stack, the C heap, or the D heap managed by a

 

GC.free(ptr4); // This is optional.

{{out}}

<pre>Test destructor

E is a memory-safe language and does not generally work with explicit deallocation. As in Python and Java, you can create arrays of specific data types which will, by any decent implementation, be compactly represented.

 

The above creates an array with an initial capacity of 128 bytes (1 kilobit) of storage (though it does not have any elements). (The Java type name is left-over from E's Java-scripting history and will eventually be deprecated in favor of a more appropriate name.) The array will be deallocated when there are no references to it.

 

 

To just allocate some bytes, <code>malloc</code> is used. This memory has to be <code>free</code>d again of course.

 

To increase safety and reduce memory leaks, there are specialized words available to help you manage your memory. If you use <code>&free</code> together with <code>with-destructors</code> your memory gets freed even in the presence of exceptions.

 

[

foo malloc-struct &free ! gets freed at end of the current with-destructors scope

! do stuff

Memory allocated with any of these malloc variants resides in the (non-garbage-collected) heap.

 

===Dictionary===

All Forth implementations have a stack-like memory space called the ''dictionary''. It is used both for code definitions and data structures.

here . \ current dictionary memory pointer

: mem, ( addr len -- ) here over allot swap move ;

create struct 0 , 10 , char A c, ," string"

unused .

 

Dictionary space is meant for static code definitions and supporting data structures, so it is not as easy to deallocate from it. For ad-hoc allocations without intervening definitions, you may give a negative value to ALLOT to reclaim the space. You may also lay down a named MARKER to reclaim the space used by all subsequent definitions.

: temp ... ;

create dummy 300 allot

-150 allot \ trim the size of dummy by 150 bytes

 

===Heap===

Most Forth implementations also give access to a larger random-access memory heap.

dup 4096 erase

 

=={{header|Fortran}}==

implicit none

real, dimension(:), allocatable :: vector

deallocate(matrix) ! Deallocate a matrix

deallocate(ptr) ! Deallocate a pointer

 

 

{{trans|BBC BASIC}}

===Heap===

Dim As Integer mem = size-1

Print size; " bytes of heap allocated at " ; mem

Clear (mem, , 10)

Memory allocated from the heap is only freed on program termination or CLEAR

 

===Stack===

Dim As Integer mem = size-1

 

 

Stack(size)

Memory allocated from the stack is freed on exit from the Sub/Function

 

=={{header|Go}}==

All memory in Go is transparently managed by the runtime and the language specification does not even contain the words stack or heap. Behind the scenes it has a single shared heap and a stack for each goroutine. Stacks for goroutines are initially 4K, but grow dyanamically as needed. Function parameters and variables declared within a function typically live on the stack, but the runtime will freely move them to the heap as needed. For example, in

x := n + 1

println(x)

Parameter n and variable x will exist on the stack.

x := n + 1

return &x

In the above, however, storage for x will be allocated on the heap because this storage is still referenced after inc returns.

 

In general, taking the address of an object allocates it on the heap. A conseqence is that given

the following two expressions are equivalent.

Yes, new allocates on the heap.

 

 

Examples,

make(map[int]int)

 

=={{header|Haskell}}==

You usually only need to do low-level memory management in Haskell when interfacing with code written in other languages (particularly C). At its most basic level, Haskell provides malloc()/free()-like operations in the IO monad.

 

 

bytealloc :: IO ()

allocaBytes 100 $ \a -> -- Allocate 100 bytes; automatically

-- freed when closure finishes

 

Slightly more sophisticated functions are available for automatically determining the amount of memory necessary to store a value of a specific type. The type is determined by type inference (in this example I use explicit manual type annotations, because poke is polymorphic).

 

 

typedalloc :: IO ()

poke w (100 :: Word32)

free w

 

By the typing rules of Haskell, w must have the type 'Ptr Word32' (pointer to 32-bit word), which is how malloc knows how much memory to allocate.

Icon and Unicon provide fully automatic memory allocation. Memory is allocated when each

structure is created and reclaimed after it is no longer referenced. For example:

t := table() # The table's memory is allocated

#... do things with t

t := &null # The table's memory can be reclaimed

For structures whose only reference is held in a local variable, that reference is removed

when the local context is exited (i.e. when procedures return) and the storage is then

Example of explicit [http://www.jsoftware.com/help/user/memory_management.htm memory allocation]:

 

mema 1000

 

Here, 57139856 is the result of mema -- it refers to 1000 bytes of memory.

To free it:

 

 

=={{header|Java}}==

You don't get much control over memory in Java, but here's what you can do:

//their scope and there are no more pointers to the objects

Object foo = new Object(); //Allocate an Object and a reference to it

int[] fooArray = new int[size]; //Allocate all spaces in an array and a reference to it

There is no real destructor in Java as there is in C++, but there is the <tt>finalize</tt> method. From the [http://java.sun.com/javase/6/docs/api/java/lang/Object.html#finalize() Java 6 JavaDocs]:

 

''The general contract of finalize is that it is invoked if and when the JavaTM virtual machine has determined that there is no longer any means by which this object can be accessed by any thread that has not yet died, except as a result of an action taken by the finalization of some other object or class which is ready to be finalized. The finalize method may take any action, including making this object available again to other threads; the usual purpose of finalize, however, is to perform cleanup actions before the object is irrevocably discarded. For example, the finalize method for an object that represents an input/output connection might perform explicit I/O transactions to break the connection before the object is permanently discarded.''

//...other methods/data members...

protected void finalize() throws Throwable{

}

//...other methods/data members...

 

Note, though, that there is '''''no guarantee''''' that the <tt>finalize</tt> method will ever be called, as this trivial program demonstrates:

public static final void main(String[] params) {

NoFinalize nf = new NoFinalize();

System.out.println("finalized");

}

 

When run using Sun's JVM implementation, the above simply outputs "created". Therefore, you cannot rely on <tt>finalize</tt> for cleanup.

=={{header|Julia}}==

Julia has memory management. Objects are freed from memory automatically. Because arrays such as vectors and matrices, unlike lists, can have fixed size allocations in memory, these can be allocated implicitly with a call to a function returning a vector, or explicitly by assigning the memory to a variable:

matrix = Array{Float64,2}(100,100)

matrix[31,42] = pi

 

=={{header|Kotlin}}==

 

Some examples may help to make all this clear. In the interests of clarity, types have been specified for all variables though, in practice, this would be unnecessary in those cases where the variable's type can be inferred from the value assigned to it when it is declared. 'val' variables are read-only but 'var' variables are read/write.

 

class MyClass(val myInt: Int) {

println(j)

// 'j' becomes eligible for garbage collection here as no longer used

When this is run, notice that finalize() is not called - at least on my machine (running UBuntu 14.04, Oracle JDK 8):

{{out}}

=={{header|Lingo}}==

Lingo does not allow direct memory allocation and has no direct access to memory types like heap, stack etc. But indirectly the ByteArray data type can be used to allocate memory that then later can be filled with custom data:

ba = byteArray(102400)

 

-- Lingo uses garbage-collection, so allocated memory is released when no more references exist.

-- For the above variable ba, this can be achieved by calling:

 

=={{header|M2000 Interpreter}}==

We can use Eval$(Mem1) to get a copy of a buffer in a string.

Statement Return used to place in many offsets data in one statement.

Module Checkit {

Buffer Clear Mem1 as Byte*12345

}

Checkit

 

=={{header|Maple}}==

 

You can allocate a large block of memory by creating an Array

Now you can use the storage in the Array assigned to <tt>a</tt> as you see fit. To ensure that <tt>a</tt> is garbage collected at the earliest opportunity, unassign the name <tt>a</tt>:

or

 

=={{header|Mathematica}}/{{header|Wolfram Language}}==

Matlab and Octave allocate memory when a new variable or a local variable is generated. Arrays are automatically extended as needed. However, extending the array might require to re-allocate the whole array. Therefore, pre-allocating memory can provide a significant performance improvement.

 

A = zeros(1000); % allocates memory for a 1000x1000 double precision matrix.

clear A; % deallocates memory

b(k) = 5*k*k-3*k+2;

end

 

=={{header|Maxima}}==

Here is how to check available memory */

 

97138 pages available

11399 pages in heap but not gc'd + pages needed for gc marking

 

=={{header|Nanoquery}}==

Even though the Nanoquery interpreter is implemented in Java, it is possible to use the native library to directly allocate and access memory located off the heap. In this example, 26 bytes are allocated, filled with the uppercase alphabet, then output to the console. Even though this code is running in the JVM, the allocated memory must still be freed at the end or a leak would occur.

 

// allocate 26 bytes

 

// free the allocated memory

{{out}}

<pre>ABCDEFGHIJKLMNOPQRSTUVWXYZ</pre>

=={{header|Nim}}==

Usually in Nim we have automated memory allocation and garbage collection, but we can still manually get a block of memory:

var a = alloc(1000)

dealloc(a)

p = nil # set pointer to nil

echo isNil(p) # true

 

=={{header|Objeck}}==

In Objeck space for local variables is allocated when a method/function is called and deallocated when a method/function exits. Objects and arrays are allocated from the heap and their memory is managed by the memory manager. The memory manager attempts to collect memory when an allocation threshold is met or exceeded. The memory manger uses a mark and sweep [[Garbage collection|garbage collection]] algorithm.

foo_array := Int->New[size]; // allocates an integer array on the heap

 

=={{header|Oforth}}==

 

You can allocate a block of memory (on the heap) by creating a MemBuffer object, which is an array of bytes.

 

=={{header|PARI/GP}}==

All accessible memory in GP is on PARI's heap. Its size can be changed:

to allocate 100 MB.

 

=== Heap ===

 

Their creation and destruction is done explicitly.

TByteArray = array of byte;

var

...

setLength(A,0);

 

Tcl = class

dummy: longint;

...

c1.destroy;

 

=={{header|Perl}}==

allocation routines (allocate and allocate_string) to automate that for you, or you could even roll your own via delete_routine().

 

<span style="color: #004080;">atom</span> <span style="color: #000000;">addr</span> <span style="color: #0000FF;">=</span> <span style="color: #7060A8;">allocate</span><span style="color: #0000FF;">(</span><span style="color: #000000;">512</span><span style="color: #0000FF;">)</span> <span style="color: #000080;font-style:italic;">-- limit is 1,610,612,728 bytes on 32-bit systems</span>

<span style="color: #0000FF;">...</span>

<span style="color: #004080;">atom</span> <span style="color: #000000;">addr2</span> <span style="color: #0000FF;">=</span> <span style="color: #7060A8;">allocate</span><span style="color: #0000FF;">(</span><span style="color: #000000;">512</span><span style="color: #0000FF;">,</span><span style="color: #000000;">1</span><span style="color: #0000FF;">)</span> <span style="color: #000080;font-style:italic;">-- automatically freed when addr2 drops out of scope or re-assigned</span>

<span style="color: #004080;">atom</span> <span style="color: #000000;">addr3</span> <span style="color: #0000FF;">=</span> <span style="color: #7060A8;">allocate_string</span><span style="color: #0000FF;">(</span><span style="color: #008000;">"a string"</span><span style="color: #0000FF;">,</span><span style="color: #000000;">1</span><span style="color: #0000FF;">)</span> <span style="color: #000080;font-style:italic;">-- automatically freed when addr3 drops out of scope or re-assigned</span>

 

Behind the scenes, the Phix stack is actually managed as a linked list of virtual stack blocks allocated on the heap, and as such it

* On the stack: this happens with variables declared as automatic in procedures and begin blocks. The variables are automatically freed when at exit of the procedure or block. If an ''init'' clause is specified, the variable will also be (re-)initialized upon entry to the procedure or block. If no ''init'' clause is specified, the variable will most likely contain garbage. An example:

 

mainproc: proc options(main) reorder;

 

call subproc();

call subproc();

 

Result:

* On the heap: if a variable is declared with the ''ctl'' (or in full, ''controlled'') attribute, it will be allocated from the heap and multiple generations of the same variable can exist, although only the last one allocated can be accessed directly. An example:

 

mainproc: proc options(main) reorder;

dcl ctlvar char ctl;

put skip data(ctlvar);

free ctlvar;

 

Result:

* On the heap: if a variable is declared with the ''based'' attribute, it will be allocated from the heap and multiple generations of the same variable can exist. This type of variable is often used in linked lists. An example:

 

mainproc: proc options(main) reorder;

dcl list_ptr ptr init (sysnull());

put skip list(list_data);

end;

Result:

 

=={{header|PureBasic}}==

 

*newBuffer = ReAllocateMemory(*buffer, 2000) ;increase size of buffer

; allocate an image for use with image functions

CreateImage(1,size,size)

 

Memory for strings is handled automatically from a separate memory heap. The automatic handling of string memory includes garbage collection and the freeing of string memory.

 

'''Example'''

>>> argslist = [('l', []), ('c', 'hello world'), ('u', u'hello \u2641'),

('l', [1, 2, 3, 4, 5]), ('d', [1.0, 2.0, 3.14])]

array('l', [1, 2, 3, 4, 5])

array('d', [1.0, 2.0, 3.1400000000000001])

 

=={{header|R}}==

rm(x) # remove x

 

x=vector("list",10) #allocate a list of length 10

x=vector("numeric",10) #same as x=numeric(10), space allocated to list vector above now freed

 

=={{header|Racket}}==

Racket doesn't allow direct memory allocation, although it supports some things

(collect-garbage) ; This function forces a garbage collection

 

; If amount of bytes can't be reached, <stop-custodian> is shutdown

 

 

Custodians manage threads, ports, sockets, etc.

 

Like Perl 5, Raku is intended to run largely stackless, so all allocations are really on the heap, including activation records. Allocations are managed automatically. It is easy enough to allocate a memory buffer of a particular size however, if you really need it:

 

=={{header|Retro}}==

Retro's memory is directly accessible via '''fetch''' and '''store'''. This is used for all functions and data structures. A variable, '''Heap''', points to the next free address. '''allot''' can be used to allocate or free memory. The amount of memory varies by the runtime, and can be accessed via the '''EOM''' constant.

 

 

~~~

~~~

#-500 allot

 

=={{header|REXX}}==

<br>Most REXX interpreters will obtain a chunk (block) of free storage, and then allocate storage out of that pool if possible, if not, obtain more storage.

<br>One particular implementation of REXX has predefined and limited amount of free storage.

There is no explicit way to de-allocate memory, but there is a DROP statement that "un-defines" a REXX variable and it's memory is then free to be used for other variables, provided that free memory isn't too fragmented.

 

Any variables (that are non-exposed) which are defined (allocated) in a procedure/subroutine/function will be un-allocated at the termination (completion, when it RETURNS or EXITs) of the procedure/subroutine/function.

<br><br>

 

=={{header|Ring}}==

cVar = " " # create variable contains string of 5 bytes

cVar = NULL # destroy the 5 bytes string !

 

=={{header|Ruby}}==

Class#allocate explicitly allocates memory for a new object, inside the [[garbage collection|garbage-collected heap]]. Class#allocate never calls #initialize.

 

def initialize

fail 'not yet implemented'

end

end

 

=={{header|Rust}}==

https://github.com/rust-lang/rust/issues/32838

 

// we will be dereferencing a raw pointer

unsafe {

// deallocate `ptr` with associated layout `int_layout`

dealloc(ptr, int_layout);

 

=={{header|Scala}}==

 

If you want to allocate an arbitrary block of bytes that the interpreter will not interfere with, there are two ways to do it. The first is by altering the system variable <tt>RAMTOP</tt>: this is a 16-bit value stored in little-endian format at addresses 16388 and 16389, and tells BASIC the highest byte it can use. On a 1k ZX81, <tt>RAMTOP</tt> equals 17408 (until you change it); to find it on your system, use

You can then use <code>POKE</code> statements to reset <tt>RAMTOP</tt> to a lower value, thus reserving the space above it.

 

The second approach, suitable especially if you want to reserve a few bytes for a small machine code subroutine, is to hide the storage space you want inside a comment. When you enter a <code>REM</code> statement, the interpreter sets aside sufficient bytes to store the text of your comment <i>and then doesn't care what you put in them</i>: if you know the address where the comment is stored, therefore, you can <code>POKE</code> whatever values you like into that space. If the comment is the first line in the program, the <code>REM</code> itself will be at address 16513 and the comment text will begin at 16514 and take up one byte per character. An example, with a trivial machine code routine (it adds 3 and 4):

20 LET P$="3E03010400814FC9"

30 LET ADDR=16514

70 IF P$<>"" THEN GOTO 40

80 CLEAR

The <tt>ABCDEFGH</tt> is arbitrary: any other eight characters would work just as well. The string in line <tt>20</tt> is the hex representation of the Z80 code, which could be disassembled as:

01 04 00 ld bc,0004

81 add a, c

4f ld c, a

Line <tt>40</tt> reads a two-digit hex number and pokes its value into memory. <code>USR</code> ("user sub routine"), in line <tt>90</tt>, is a function that takes the address of a machine language routine, calls it, and returns the contents of the <tt>BC</tt> register pair when the routine terminates. Under normal circumstances, once you were satisfied the machine code program was working correctly you would remove lines <tt>20</tt> to <tt>80</tt>, leaving just the machine code subroutine and the call to it. Note that if you list the program once you have run it, the first line will look something like this:

Unfortunately, you cannot type that in directly: not all 256 possible values are accessible from the keyboard, so there is no point trying to learn to enter machine code in that form.

 

{{works with|Smalltalk/X}}

To allocate a non-movable, non garbage collected block of memory, eg. to hand out a block of memory on which an external C-function keeps a reference. The memory must be eventually explicitly freed by the programmer:

...

To allocate a non-movable block of memory, which is garbage collected as soon as the reference is no longer reachable by Smalltalk (to hand out a block of memory to an external function which does NOT keep a reference on it):

...

handle := nil "or no longer reachable"

...

 

Of course, both are to be used with great care, as memory leaks are possible. Thus, it is only used by core parts of the system, eg. for async I/O buffers, shared memory, mapped I/O devices etc. Normal programs would not use them.

In SNOBOL4, simple data values are just created and assigned to variables. Here, three separate strings are concatenated and stored as a newly allocated string variable:

 

 

Empty arrays are created by using the built-in function (the size is determined when it is created):

 

 

Empty tables are similarly created using the built-in function (new entries can be simply added at any later time by just storing them into the table):

 

 

User-defined datatypes (usually, multi-field structures) are defined using the data() built-in function (which creates the constructor and field access functions):

 

 

Then you allocate a new example of the defined listnode data item by using the constructor the data() function created:

 

 

The example thus created can be updated using the field access functions also created by the data() function:

 

 

You don't need to explicitly de-allocate memory. When you leave a function which has declared local variables, data stored in those local variables is released upon return. You can also just store a null string into a variable, releasing the value that was stored in that variable previously:

 

 

SNOBOL4 automatically garbage collects released data items on an as-needed basis, and moves allocated items to consolidate all released space (so memory fragmentation is never a problem). You can explicitly garbage collect if you really want to:

 

 

=={{header|Tcl}}==

 

More commonly, a package written in [[C]] will be used to manage the memory on behalf of Tcl, with explicit memory management. Here is an example of such a package:

 

/* A data structure used to enforce data safety */

/* Register the package */

return Tcl_PkgProvide(interp, "memalloc", "1.0");

 

The package would then be used like this:

 

set block [memalloc 1000]

someOtherCommand [memaddr $block]

puts "$block\[42\] is now [memget $block 42]"

 

Other methods of performing things like memory allocation are also possible.

 

The only type of memory allocation where the programmer has any control is the initial number of elements of a List though even here additional elements can be allocated by simply adding them.

var squares = List.filled(10, 0)

// give them different values and print them

squares.add(10 * 10)

System.print(squares)

 

{{out}}

This is a bare-bones implementation of a heap memory allocator for x86_64 Linux. We alloctate memory page at a time using brk and divide up the memory in chunks of requested size using a linked list-like block struct. Not optimized for speed or efficiency.

 

; linux x86_64

 

ret

 

 

=={{header|XPL0}}==

Array2:= Reserve(10*4); \another way to allocate 10 integers of heap space

Array3:= MAlloc(4); \allocate 4 paragraphs (64 bytes) of conventional memory

...

 

Heap space (for 32-bit XPL0) resides in extended memory (on an

 

Extension libraries/DLLs (written in C) can add this capability (the FFI library does this).

 

=={{header|ZX Spectrum Basic}}==

On the ZX Spectrum, memory above the ramtop is protected, so the usual way to reserve memory is to move the ramtop to a lower address using a clear command. The following example assumes that a 48k ZX Spectrum is being used:

 

20 CLEAR 65535 - 8192: REM reserve 8192 bytes of memory

 

{{omit from|ACL2}}