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

[David Froble]

Stephen Hoffman wrote:
> 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.
> 
> 
> 

Interesting.  I wasn't aware that the virtual address space wasn't pared 
down when releasing memory.  But, as you've mentioned, virtual address 
space is rather cheap, and can have no adverse affect on physical memory.