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

[Johnny Billquist]

On 2013-10-14 03:02, David Froble wrote:
> 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.

Indeed. But if you look with top, or other system tools, at the virtual 
memory size, this memory is in there. Which is why you should not 
necessarily put too much significance in how much virtual memory a 
process have allocated.

	Johnny

-- 
Johnny Billquist                  || "I'm on a bus
                                   ||  on a psychedelic trip
email: bqt at softjar.se             ||  Reading murder books
pdp is alive!                     ||  tryin' to stay hip" - B. Idol