Ml Kit

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

: Is that the same as Arenas?

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 DataBases and files in FileSystems)

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

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