The ML Kit is a compiler for the Standard ML programming language that uses RegionBasedMemoryManagement.

	 :	''Is that the same as Arenas?''

See http://www.it-c.dk/research/mlkit/

See also: SmlLanguage, CycloneLanguage.

----

  What "Arenas" ?  -- StefanLjungstrand

'''Arenas''' are a technique used in memory management in which a lump of memory is allocated on entry to a procedure (or whatever) and then smaller bits within it are given out when requested. When the procedure exits it can deallocate the entire lump in one go rather than having to deallocate the individual pieces. The big lump is called an '''arena'''. The technique applies in obvious ways to other contexts such as objects.

This appears to be different from what's described on the above referenced web-site, which the original questioner clearly didn't bother to read. There it says:

	 :	All memory allocation directives (both allocation and de-allocation) are inferred by the compiler, which uses a number of program analyses concerning lifetimes and storage layout. The ML Kit is unique among ML implementations in this respect.

----

Hmm, IIRC the Region idea in The ML Kit went something like this :
(CMIIAW with details here)

The most common place(/extent) of allocating storage are :
* PersistentAllocation survives processes. Explicit creation and deletion are most often used.
	(E.g. data in DataBase''''''s and files in FileSystem''''''s)
* StaticAllocation is alive during process lifetime.
	(E.g. in C : (exported and nonexported) static file-scope, and static in function bodies.)
	(One could perhaps handle temporary files with this extent ...)
* StackAllocation follows BlockStructure and prodecure/function/method entry and exit.
	(The "usual" extent, invented in AlgolLanguage IIRC.)
	(One could perhaps also imagine temporary files handled with this extent ...)
* HeapAllocation extends from (probably) explicit point of allocation to either GarbageCollection or explicit point of deallocation (or possibly process termination (or OperatingSystem termination).)

So, what is the RegionAllocationExtent ?

As far as I can see, It's a variant of StackAllocation, but, instead of allocating a frame/region at just directly around the code declaring (and using) some variables, we can optionally allocate the frame/region higher-up in the call hierarchy.

E.g. : LexicalClosure''''''s

(Sorry, don't have time to complete this ATM, some more will come here.)

-- StefanLjungstrand

----

Definitely a variant (or extension) of StackAllocation. 
The big difference is that while the regions themselves
are created and deleted in a stack-wise manner, the objects are not.
Every allocation takes as an additional argument the region in which 
the memory is allocated. Functions that return a heap-allocated object need to
accept one (or possibly more) regions as arguments so that they know in
which region they should produce the answer.

Of course, the previous paragraph assumes manual region annotation, the point
of the MlKit is that it can do all this creation and passing around of regions
automatically.

Automatic region inference is "incomparable" with tracing GarbageCollection, which
means that in some cases it cleans up more than tracing GC would, in other cases
it cleans up less.


EditHint: move to RegionBasedMemoryManagement.