[Info-vax] Memory Management (was Re: Running Alpha VMS under the ES40 emulator)

[Stephen Hoffman]

On 2013-10-13 18:23:03 +0000, David Froble said:

> In my database product, memory is acquired for I/O buffers and other 
> data structures.  When a file is closed, all the memory is returned to 
> the OS.  It's not rocket science, just good design and coding ...

VMS expands the number of virtual pages associated with the program 
region via $cretva and $expreg calls, but doesn't free the allocated 
address space except via $rundwn call, or in response to an express 
user call.  Applications that make $deltva calls are rare, and 
applications that seek to return virtual address space are very rare.

Put another way, the virtual address space isn't returned when you 
deallocate the memory in your application, and VMS constructs such as 
the heap or the stack are never reduced in virtual size.  Available for 
reuse by the application, yes, but the virtual address space is not 
returned.

Beyond DCL, very few applications use the mode-specific $rundwn, and 
most folks flush the whole process to free up the resources.

Physical memory potentially referenced by the virtual address space can 
and does get paged out, where that's permitted.

Now virtual address space is pretty cheap, which is why few folks even 
notice this behavior.  (This cheapness is also at the core of

There's an intro here <http://labs.hoffmanlabs.com/node/228> and some 
related details here <http://labs.hoffmanlabs.com/node/461>

Further up the stack from how VMS deals with this stuff, there's a 
discussion of compiler- and run-time level garbage collection, and of 
acquiring and freeing physical memory.   At the application level, 
garbage collection works quite well in the languages and run-times that 
offer it, and I see no reason to avoid garbage collection in general.  
Garbage collection frees the physical memory, but (at least on VMS) 
does not free the virtual address space.  For most applications, not 
having to manually manage memory blocks is a whole lot like not having 
to chase processor register allocations and register mapping around in 
application code; it's very handy.   Manual memory management is 
tedious.  <http://labs.hoffmanlabs.com/node/263>

Since there's inevitably somebody in these threads that'll be working 
with some weird or specialized or boutique application, yes, there are 
certain applications where garbage collection can be inadvisable or 
inappropriate.  These cases are rare and involve specialized 
applications, and usually include tight run-time response requirements 
and response predictability, embedded or task-dedicated processing, or 
memory constraints.  If you're stupid enough to use garbage collection 
where it doesn't belong, well, you probably get what you deserve if you 
try it.



-- 
Pure Personal Opinion | HoffmanLabs LLC