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)

 

=={{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

Test destructor

</pre>

=={{header|E}}==

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

 

=={{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|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|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

 

Mathematica allocates memory and garbage collects it.

 

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|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)

# Allocate memory block on shared heap

var b = allocShared(1000)

 

=={{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|Phix}}==

In normal use, memory management is fully automatic in Phix. However you may need to explicitly allocate memory when interfacing to C etc.

By default (for compatibility with legacy code) cleanup must be performed manually, but there is an optional flag on both the memory

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

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

would be utterly pointless and quite probably extremely tricky to mess with.

* 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.

A bit of information about them is available [http://docs.racket-lang.org/reference/eval-model.html?q=memory&q=custodian&q=computer&q=pointer#%28part._custodian-model%29 here]

 

=={{header|Retro}}==

 

 

 

 

 

 

=={{header|REXX}}==

There is no explicit memory allocation in the REXX language, &nbsp; variables are allocated as they are assigned &nbsp; (or re-assigned).

<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.

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|Scala}}==

The same as Java applies to Scala, because the VM will take of memory allocation by means of the Memory Manager. In Scala it's not a programmer concern.

 

=={{header|SNOBOL4}}==

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.

* Using <code>string repeat</code> or <code>lrepeat</code> to make a group of entities that work like a block of memory (despite not being); these need marshalling code to bridge to foreign function interfaces.

* Using [[:Category:SWIG|SWIG]] or [[:Category:critcl|critcl]] to write a bridge to a standard [[C]] allocator.

 

=={{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}}