[Search for users] [Overall Top Noters] [List of all Conferences] [Download this site]

Conference turris::decc

Title:	DECC
Notice:	General DEC C discussions
Moderator:	TLE::D_SMITHNTE

Created:	Fri Nov 13 1992
Last Modified:	Fri Jun 06 1997
Last Successful Update:	Fri Jun 06 1997
Number of topics:	2212
Total number of notes:	11045

2124.0. "max size of malloc() on OpenVMS Alpha V7? I get 603979768 (Hex 23FFFFF8)" by HYDRA::NEWMAN (Chuck Newman, 508/467-5499 (DTN 297), MRO1-3/F26) Wed Mar 19 1997 13:10

I assume that this is limited by the process private region's
list of unused blocks, but I can't figure much out from the OpenVMS IDS.

This has to be called from FORTRAN, so _malloc64 doesn't appear to be an
option.

I would have expected to be able to allocate closer to 1 GB - image size from
map file.

pagefilequota, page file size, and wsquota are all quite healthy.


Here's the program I used:

cdec$ alias malloc, 'decc$malloc'
cdec$ alias free, 'decc$free'
        double precision array(1000*1024*1024/8)
        volatile array_ptr
        pointer (arr_ptr, array)
        integer*8 high, low, test
        integer status, errno
        pointer (errno_ptr, errno)
        integer CMA$TIS_ERRNO_GET_ADDR, CMA$TIS_VMSERRNO_GET_ADDR
        external CMA$TIS_ERRNO_GET_ADDR, CMA$TIS_VMSERRNO_GET_ADDR
        high = 1024 * 1024
        high = high * 1024
        low = 0
        do while (high .ne. low+1)
          test = (high + low)/2
          arr_ptr = malloc(%val(test))
          if (arr_ptr .eq. 0) then
            high = test
            errno_ptr = CMA$TIS_ERRNO_GET_ADDR()
            if (errno .eq. 65535) then
              errno_ptr = CMA$TIS_VMSERRNO_GET_ADDR()
              type *, 'VMS error', errno
            else
              type *, 'C error', errno
            end if
          else
            low = test
            status = free(array)
          end if
        end do
        arr_ptr = malloc(%val(low))
        type *, 'The most I could allocate was', low
        type *, 'The returned address was', arr_ptr
        type *, 'An allocation of', high, ' bytes failed.'
        array(1) = 1
        array(low/8) = -1
        status = free(array)
        stop
        end
--------------------------------------------------------------------------------
Here's the output:
C error          12
C error          12
C error          12
C error          12
C error          12
C error          12
The most I could allocate was             603979768
The returned address was               4642584
An allocation of             603979769 bytes failed.

T.R	Title	User	Personal Name	Date	Lines
2124.1	Why C calls and not lib$get_vm_64?	XDELTA::HOFFMAN	Steve, OpenVMS Engineering	`Wed Mar 19 1997 14:16`	12
	Why are you calling C RTL routines from Fortran, and not the documented RTL lib$ virtual memory routines? The C RTL memory routines and the RTL lib$ routines can fully coexist in an application, though they work from different memory pools and thus the C and RTL routine calls should not be intermixed on the same block(s) of memory. In OpenVMS Alpha V7.0 and later, one can allocate and use 64-bit (P2) space, with RTL lib$ calls such as lib$get_vm_64(). And if you haven't already done so, see the _OpenVMS Alpha Guide to 64-Bit Addressing_ manual in the V7.0 and later documentation set.
2124.2	sys$expreg is the winner	HYDRA::NEWMAN	Chuck Newman, 508/467-5499 (DTN 297), MRO1-3/F26	`Thu Mar 20 1997 11:22`	26
	� Why are you calling C RTL routines from Fortran, and not the documented � RTL lib$ virtual memory routines? The C RTL memory routines and the RTL � lib$ routines can fully coexist in an application, though they work from � different memory pools and thus the C and RTL routine calls should not be � intermixed on the same block(s) of memory. I used malloc because that's what the application does (from a C routine, I believe). Their code isn't yet 64-bit safe (store addresses in integers, etc.) I tried LIB$GET_VM, but couldn't get any more than with malloc() I then tried LIB$CREATE_VM_ZONE. I could make a larger zone, but if I immediately turned around and deleted it via LIB$DELETE_VM_ZONE I couldn't create one again of the same size (I was doing a binary search to see how big I could create one). I then tried SYS$EXPREG which appears to work great -- it gave me all the way to the end of P0 space. Should there be a guard page after that (i.e., at the end of P1 space, address 0000000040000000)? There doesn't appear to be since I can write there. This is getting pretty far from DEC C discussion. -- Chuck Newman
2124.3	Allocate once and for all?	WIBBIN::NOYCE	Pulling weeds, pickin' stones	`Thu Mar 20 1997 13:40`	3
	If you call SYS$EXPREG, do you ever intend to give the memory back (via SYS$DELTVA)? Do you expect that memory to become available to malloc or LIB$GET_VM?
2124.4	Once and for all!	HYDRA::NEWMAN	Chuck Newman, 508/467-5499 (DTN 297), MRO1-3/F26	`Thu Mar 20 1997 14:16`	7
	I believe the intention is that the memory allocated via SYS$EXPREG will be used throughout the lifetime of the image (i.e., not returned until close to the time when the program runs down). Also, this memory should NOT be available to malloc, LIB$GET_VM, or any other possible memory allocation mechanism (the application also uses DECwindows). -- Chuck Newman
2124.5	use memory-resident sections?	CUJO::SAMPSON		`Thu Mar 20 1997 22:23`	7
	If you're on OpenVMS Alpha V7.1 or later, and you're looking for fast setup, execution, and rundown, you might want to look into using the newly-available feature of memory-resident sections. I believe they're always global (either group-wide or system-wide), but you could "privatize" them by giving each created section a unique name (e.g. containing the PID and/or thread ID). Since they have no backing store, their total size is constrained by the amount of available physical memory on the system.
2124.6	the design idea needs some refinement	CUJO::SAMPSON		`Thu Mar 20 1997 22:29`	6
	Maybe identifying the section by the creator PID and/or thread isn't such a great idea, from a cleanup standpoint. It might be better to identify each section by its assigned purpose, reserving that amount of memory permanently (or until specifically released), and letting a process gain temporary or long-term ownership (e.g. by locking a resource name).