![[Digital logo]](../../IMAGES/DIGITAL-LOGO.GIF){kind=logo}
![[HR]](../../IMAGES/REDBAR.GIF)
Virtual region creation gives OpenVMS subsystems and the application programmer the ability to reserve virtual address space for expansion. For example, an application can create a large virtual region and then create some virtual addresses within that virtual region. Later, when the application requires more virtual address space, it can expand within the virtual region and create more address space in a virtually contiguous manner to the previous addresses allocated within that virtual region.
Virtual regions can also be created within P0 and P1 space by specifying VA$M_P0_SPACE or VA$M_P1_SPACE in the flags argument to the SYS$CREATE_REGION_64 service.
If you do not explicitly delete a virtual region with the SYS$DELETE_REGION_64 system service, the user-defined virtual region along with all created address space is deleted when the image exits.
New OpenVMS system services are available, and many existing services have been enhanced to manage 64-bit address space. This chapter describes the OpenVMS Alpha system services that support 64-bit addressing and VLM. It explains the changes made to 32-bit services to support 64-bit addresses, and it lists the new 64-bit system services.
To see examples of system services that support 64-bit addressing in an application program, refer to Appendix C. For complete information about the OpenVMS system services listed in this chapter, see the OpenVMS System Services Reference Manual: A--GETMSG and OpenVMS System Services Reference Manual: GETQUI--Z.
The following system services definitions are used throughout this guide.
32-bit system service
A 32-bit system service is a system service that only supports 32-bit addresses on any of its arguments that specify addresses. If passed by value, on OpenVMS Alpha a 32-bit virtual address is actually a 64-bit address that is sign-extended from 32-bits.64-bit friendly interface
A 64-bit friendly interface is an interface that can be called with all 64-bit addresses. A 32-bit system service interface is 64-bit friendly if, without a change in the interface, it needs no modification to handle 64-bit addresses. The internal code that implements the system service might need modification, but the system service interface will not.The majority of OpenVMS Alpha system services prior to OpenVMS Alpha Version 7.0 have 64-bit friendly interfaces for the following reasons:
- The OpenVMS Calling Standard defines arguments to standard routines to be 64 bits wide. The caller of a routine sign-extends 32-bit arguments to be 64 bits.
- 64-bit string descriptors can be distinguished from 32-bit string descriptors at run time. (See the OpenVMS Calling Standard for more information about 64-bit descriptors.)
- User visible RMS data structures contain embedded type information such that the RMS routines can tell whether an extended form of a structure is being used. (See Chapter 5 for more details about RMS 64-bit addressing support.)
Examples of 64-bit friendly system services are $QIO, $SYNCH, $ENQ, and $FAO.
Examples of routines with 64-bit unfriendly interfaces are most of the memory management system services, such as $CRETVA, $DELTVA, and $CRMPSC. The INADR and RETADR argument arrays do not promote easily to hold 64-bit addresses.
64-bit system service
A 64-bit system service is a system service that is defined to accept all address arguments as 64-bit addresses (not necessarily 32-bit sign-extended values). Also, a 64-bit system service uses the entire 64 bits of all virtual addresses passed to it.The 64-bit system services include the _64 suffix for services that accept 64-bit addresses by reference. For promoted services, this distinguishes the 64-bit capable version from its 32-bit counterpart. For new services, it is a visible reminder that a 64-bit wide address cell will be read/written. This is also used when a structure is passed that contains an embedded 64-bit address, if the structure is not self-identifying as a 64-bit structure. Hence, a routine name need not include "_64" simply because it receives a 64-bit decriptor. Remember that passing an arbitrary value by reference does not mean the suffix is required; passing a 64-bit address by reference does.
Table 3-1 summarizes the OpenVMS Alpha system services that support 64-bit addresses.
Although RMS system services provide some 64-bit addressing capabilities, they are not listed in this table because they are not full 64-bit system services. See Chapter 5 for more details.
| Service | Arguments |
|---|---|
| Alignment System Services | |
| $GET_ALIGN_FAULT_DATA | buffer_64, buffer_size, return_size_64 |
| $GET_SYS_ALIGN_FAULT_DATA | buffer_64, buffer_size, return_size_64 |
| $INIT_SYS_ALIGN_FAULT_REPORT | match_table_64, buffer_size, flags |
| AST System Service | |
| $DCLAST | astadr_64, astprm_64, acmode |
| Condition Handling System Services | |
| $FAO | ctrstr_64, outlen_64, outbuf_64, p1_64...pn_64 |
| $FAOL | ctrstr_64, outlen_64, outbuf_64, long_prmlst_64 |
| $FAOL_64 | ctrstr_64, outlen_64, outbuf_64, quad_prmlst_64 |
| $GETMSG | msgid, msglen_64, bufadr_64, flags, outadr_64 |
| $PUTMSG | msgvec_64, actrtn_64, facnam_64, actprm_64 |
| $SIGNAL_ARRAY_64 | mcharg, sigarg_64 |
| CPU Scheduling System Services | |
| $CPU_CAPABILITIES | cpu_id, select_mask, modify_mask, prev_mask, flags |
| $FREE_USER_CAPABILITY | cap_num, prev_mask, flags |
| $GET_USER_CAPABILITY | cap_num, select_num, select_mask, prev_mask, flags |
| $PROCESS_AFFINITY | pidadr, prcnam, select_mask, modify_mask, prev_mask, flags |
| $PROCESS_CAPABILITIES | pidadr, prcnam, select_mask, modify_mask, prev_mask, flags |
| $SET_IMPLICIT_AFFINITY | pidadr, prcnam, state, cpu_id, prev_mask |
| Event Flag System Service | |
| $READEF | efn, state_64 |
| Fast-I/O System Services | |
| $IO_CLEANUP | fandle |
| $IO_PERFORM | fandle, chan, iosadr, bufadr, buflen, porint |
| $IO_PERFORMW | fandle, chan, iosadr, bufadr, buflen, porint |
| $IO_SETUP | func, bufobj, iosobj, astadr, flags, return_fandle |
| I/O System Services | |
| $QIO(W)¹ | efn, chan, func, iosb_64, astadr_64, astprm_64, p1_64, p2_64, p3_64, p4_64, p5_64, p6_64 |
| $SYNCH | efn, iosb_64 |
| Locking System Services | |
| $DEQ | lkid, vablk_64, acmode, flags |
| $ENQ(W) | efn, lkmode, lksb_64, flags, resnam_64, parid, astadr_64, astprm_64, blkast_64, acmode |
| Logical Name System Services | |
| $CRELNM | attr, tabnam, lognam, acmode, itmlst |
| $CRELNT | ttr, resnam, reslen, quota, promsk, tabnam, partab, acmode |
| $DELLNM | tabnam, lognam, acmode |
| $TRNLNM | attr, tabnam, lognam, acmode, itmlst |
| Memory Management System Services | |
| $ADJWSL | pagcnt, wsetlm_64 |
| $CREATE_BUFOBJ_64 | start_va_64, length_64, acmode, flags, return_va_64, return_length_64, return_buffer_handle_64 |
| $CREATE_GDZRO | gsdnam_64, ident_64, prot, length_64, acmode, flags, ... |
| $CRMPSC_GDZRO_64 | gsdnam_64, ident_64, prot, length_64, region_id_64, section_offset_64, acmode, flags, return_va_64, return_length_64, ... |
| $CREATE_GFILE | gsdnam_64, ident_64, file_offset_64, length_64, chan, acmode, flags, return_length_64, ... |
| $CREATE_GPFILE | gsdnam_64, ident_64, prot, length_64, acmode, flags |
| $CREATE_GPFN | gsdnam_64, ident_64, prot, start_pfn, page_count, acmode, flags |
| $CREATE_REGION_64 | length_64, region_prot, flags, return_region_id_64, return_va_64, return_length_64, ... |
| $CRETVA_64 | region_id_64, start_va_64, length_64, acmode, flags, return_va_64, return_length_64 |
| $CRMPSC_FILE_64 | region_id_64, file_offset_64, length_64, chan, acmode, flags, return_va_64, return_length_64, ... |
| $CRMPSC_GFILE_64 | gsdnam_64, ident_64, file_offset_64, length_64, chan, region_id_64, section_offset, acmode, flags, return_va_64, return_length_64, ... |
| $CRMPSC_GPFILE_64 | gsdnam_64, ident_64, prot, length_64, region_id_64, section_offset_64, acmode, flags, return_va_64, return_length_64, ... |
| $CRMPSC_GPFN_64 | gsdnam_64, ident_64, prot, start_pfn, page_count, region_id_64, relative_page, acmode, flags, return_va_64, return_length_64, ... |
| $CRMPSC_PFN_64 | region_id_64, start_pfn, page_count, acmode, flags, return_va_64, return_length_64, ... |
| $DELETE_BUFOBJ | buffer_handle_64 |
| $DELETE_REGION_64 | region_id_64, acmode, return_va_64, return_length_64 |
| $DELTVA_64 | region_id_64, start_va_64, length_64, acmode, return_va_64, return_length_64 |
| $DGBLSC | flags, gsdnam_64, ident_64 |
| $EXPREG_64 | region_id_64, length_64, acmode, flags, return_va_64, return_length_64 |
| $GET_REGION_INFO | function_code, region_id_64, start_va_64, ,buffer_length, buffer_address_64, return_length_64 |
| $LCKPAG_64 | start_va_64, length_64, acmode, return_va_64, return_length_64 |
| $LKWSET_64 | start_va_64, length_64, acmode, return_va_64, return_length_64 |
| $MGBLSC_64 | gsdnam_64, ident_64, region_id_64, section_offset_64, length_64, acmode, flags, return_va_64, return_length_64, ... |
| $MGBLSC_GPFN_64 | gsdnam_64, ident_64, region_id_64, relative_page, page_count, acmode, flags, return_va_64, return_length_64, ... |
| $PURGE_WS | start_va_64, length_64 |
| $SETPRT_64 | start_va_64, length_64, acmode, prot, return_va_64, return_length_64, return_prot_64 |
| $ULKPAG_64 | start_va_64, length_64, acmode, return_va_64, return_length_64 |
| $ULWSET_64 | start_va_64, length_64, acmode, return_va_64, return_length_64 |
| $UPDSEC_64(W) | start_va_64, length_64, acmode, updflg, efn, iosa_64, return_va_64, return_length_64, ... |
| Process Control System Services | |
| $GETJPI(W) | efn, pidadr, prcnam, itmlst, iosb, astadr, astprm |
| $PROCESS_SCAN | pidctx, itmlst |
| Time System Services | |
| $ASCTIM | timlen, timbuf, timadr, cvtflg |
| $ASCUTC | timlen, timbuf, utcadr, cvtflg |
| $BINTIM | timbuf, timadr |
| $BINUTC | timbuf, utcadr |
| $CANTIM | reqidt_64, acmode |
| $GETTIM | timadr_64 |
| $GETUTC | utcadr |
| $NUMTIM | timbuf, timadr |
| $NUMUTC | timbuf, utcadr |
| $SETIME | timadr |
| $SETIMR | efn, daytim_64, astadr_64, reqidt_64, flags |
| $TIMCON | timadr, utcadr, cvtflg |
| Other System Services | |
| $CMEXEC_64 | routine_64, quad_arglst_64 |
| $CMKRNL_64 | routine_64, quad_arglst_64 |
| $GETSYI(W) | efn, csidadr, nodename, itmlst, iosb, astadr, astprm |
| $IDTOASC | id, namlen, nambuf, resid, attrib, contxt |
OpenVMS system services not listed in Table 3-1 and all user-written system services that are not explicitly enhanced to accept 64-bit addresses will receive sign-extension checking. Any argument passed to these services that is not properly sign-extended will cause the error status SS$_ARG_GTR_32_BITS to be returned.
C function prototypes for system services are available in SYS$LIBRARY:SYS$STARLET_C.TLB (or STARLET).
No 64-bit MACRO-32 macros are available for system services. The MACRO-32 caller must use the AMACRO built-in EVAX_CALLG_64 or the $CALL64 macro. For more information about MACRO-32 programming support for 64-bit addressing, see Chapter 12.
As of OpenVMS Alpha Version 7.0, SYS$LIBRARY:SYS$STARLET_C.TLB (or STARLET) provides C function prototypes for system services, as well as new and enhanced data structure definitions. The new definitions are more consistent with the OpenVMS C language coding conventions and definitions (typedefs) used in SYS$LIBRARY:SYS$LIB_C.TLB.
In order to maintain source compatibility for existing users of STARLET.H, the old style function declarations and definitions are still provided by default. To take advantage of the new system service function prototypes and type definitions, you must explicitly enable them.
You can define the :NEW_STARLET symbol with a DEC C command line qualifier or include the definition directly in your source program. For example:
/DEFINE=(__NEW_STARLET=1)
#define __NEW_STARLET 1 #include <starlet.h> #include <vadef.h>
To see the currently available system service function prototypes in STARLET.H, you can use the Librarian Utility as shown in the following example:
$ LIBRARY/OUTPUT=STARLET.H SYS$LIBRARY:SYS$STARLET_C.TLB/EXTRACT=STARLET
The following example shows a new system service function prototype as it is defined in STARLET.H:
#pragma __required_pointer_size __long
int sys$expreg_64(
struct _generic_64 *region_id_64,
unsigned __int64 length_64,
unsigned int acmode,
unsigned int flags,
void *(*(return_va_64)),
unsigned __int64 *return_length_64);
#pragma __required_pointer_size __short
For more information about DEC C pointer size pragmas, see the DEC C User's Guide for OpenVMS Systems.
The following source code example shows the sys$expreg_64 function prototype referenced in a program.
#define __NEW_STARLET 1 /* Enable "New Starlet" features */
#include <starlet.h> /* Declare prototypes for system services */
#include <gen64def.h> /* Define GENERIC_64 type */
#include <vadef.h> /* Define VA$ constants */
#include <ints.h> /* Define 64-bit integer types */
#include <far_pointers.h> /* Define 64-bit pointer types */
{
int status; /* Ubiquitous VMS status value */
GENERIC_64 region = { VA$C_P2 }; /* Expand in "default" P2 region */
VOID_PQ p2_va; /* Returned VA in P2 space */
uint64 length; /* Allocated size in bytes */
extern uint64 page_size; /* Page size in bytes */
status = sys$expreg_64( ®ion, request_size, 0, 0, &p2_va, &length );
...
}
Table 3-2 lists the data structures that are used by the new function protypes.
| Structure Used by Prototype | Defined by Header File | Common Prefix for Structure Member Names | Description |
|---|---|---|---|
| struct _cluevthndl | cluevtdef.h | cluevthndl$ | Cluster event handle |
| struct _fabdef | fabdef.h | fab$ | File Access Block |
| struct _generic_64 | gen64def.h | gen64$ | Generic quadword structure |
| struct _ieee | ieeedef.h | ieee$ | IEEE Floating Point control structure |
| struct _ile2 ¹ | iledef.h | ile2$ | Item List Entry 2 |
| struct _ile3 ¹ | iledef.h | ile3$ | Item List Entry 3 |
| struct _ilea_64 ¹ | ilea_64$ | iledef.h | 64-bit itemlist entry A structure |
| struct _ileb_64 ¹ | ileb_64$ | iledef.h | 64-bit itemlist entry B structure |
| struct _iosa | iosadef.h | iosa$ | I/O Status Area |
| struct _iosb | iosbdef.h | iosb$ | I/O Status Block |
| struct _lksb | lksbdef.h | lksb$ | Lock Status Block |
| struct _rabdef | rabdef.h | rab$ | RMS Record Access Block |
| struct _secid | seciddef.h | secid$ | Global section identifier |
| struct _va_range | va_rangedef.h | va_range$ | 32-bit Virtual address range |
This chapter describes the following OpenVMS Alpha memory management VLM features:
To see an example program that demonstrates these VLM features, refer to Appendix D.
Memory-resident global sections allow a database server to keep larger amounts of "hot" data cached in physical memory. The database server then accesses the data directly from physical memory without performing I/O read operations from the database files on disk. With faster access to the data in physical memory, run-time performance increases dramatically.
Shared page tables allow that same database server to reduce the amount of physical memory consumed within the system. Because multiple server processes share the same physical page tables that map the large database cache, an OpenVMS Alpha system can support more server processes. This increases overall system capacity and decreases response time to client requests.
Also, with shared page tables, the database server startup time is dramatically reduced because server processes can map memory-resident global sections hundreds of times faster than traditional global sections. With a multiple giga-byte global database cache, the server startup performance gains can be significant.
As of OpenVMS Alpha Version 7.1, the system parameters GBLPAGES and GBLPAGFIL have been modified to become dynamic parameters. Users with the CMKRNL privilege can now change these parameter values on a running system. Increasing the value of the GBLPAGES parameter will allow the global page table to expand, on demand, up to the new maximum size.
The Reserved Memory Registry supports memory-resident global sections and shared page tables. Through its interface within the SYSMAN utility, the Reserved Memory Registry allows an OpenVMS system to be configured with large amounts of memory set aside for use within memory-resident sections or other privileged code. The Reserved Memory Registry also allows an OpenVMS system to be properly tuned through AUTOGEN, thus accounting for the pre-allocated reserved memory.
Memory-resident global sections are non-file backed global sections. This means that the pages within a memory-resident global section are not backed by the pagefile or by any other file on disk. Thus, no pagefile quota is charged to any process or charged to the system. When a process maps to a memory-resident global section and references the pages, working set list entries are not created for the pages. And no working set quota is charged to the process.
Pages within a memory-resident global demand zero (DZRO) section initially have zero contents.
Creating a memory-resident global DZRO section is performed by calling either the SYS$CREATE_GDZRO system service or the SYS$CRMPSC_GDZRO_64 system service.
Mapping to a memory-resident global DZRO section is performed by calling either the SYS$CRMPSC_GDZRO_64 system service or the SYS$MGBLSC_64 system service.
To create a memory-resident global section, the process must have been granted the VMS$MEM_RESIDENT_USER rights identifier. Mapping to a memory-resident global section does not require this right identifier.
Two options are available when creating a memory-resident global DZRO section:
Fault option
To use the fault option, it is recommended, but not required that the pages within the memory-resident global section be deducted from the system's fluid page count through the Reserved Memory Registry.
Using the Reserved Memory Registry ensures that AUTOGEN tunes the system properly to exclude memory-resident global section pages in its calculation of the system's fluid page count. AUTOGEN sizes the system pagefile, number of processes, and working set maximum size based on the system's fluid page count.
If the memory-resident global section has not been registered through the Reserved Memory Registry, the system service call fails if there are not enough fluid pages left in the system to accommodate the memory-resident global section.
If the memory-resident global section has been registered through the Reserved Memory Registry, the system service call fails if the size of the global section exceeds the size of reserved memory and there are not enough fluid pages left in the system to accommodate the additional pages.
If memory has been reserved using the Reserved Memory Registry, that memory must be used for the global section named in the SYSMAN command. To return the memory to the system, SYSMAN can be run to "free" the reserved memory, thus returning the pages back into the system's count of fluid pages.
If the name of the memory-resident global sections is not known at boot time, or if a large amount of memory is to be configured out of the system's pool of fluid memory, entries in the Reserved Memory Registry can be added and the system can be retuned with AUTOGEN. After the system re-boots, the reserved memory can be "freed" for use by any application in the system with the VMS$MEM_RESIDENT_USER rights identifier. This technique increases the availability of fluid memory for use within memory-resident global sections without committing which applications or named global sections will receive the reserved memory. For more information about the RESERVED_MEMORY FREE command, see Section 4.5.2.2.
Allocate option
To use the allocate option, the memory must be pre-allocated during system initialization time to ensure that contiguous, aligned physical pages are available. Granularity hints may be used when mapping to the memory-resident global section if the virtual alignment of the mapping is on an even 8 page, 64 page, or 512 page boundary. (With a system page size of 8 Kbytes, granularity hint virtual alignments are on 64 Kbyte, 512 Kbyte, and 4 Mbyte boundaries.) OpenVMS chooses optimal virtual alignment to use granularity hints if the flag SEC$M_EXPREG is set on the call to one of the mapping system services, such as SYS$MGBLSC.
Contiguous, aligned PFNs are reserved using the Reserved Memory Registry. The contiguous, aligned pages are allocated during system initialization, based on the description of the reserved memory. The memory-resident global section size must be less than or equal to the size of the reserved memory or an error is returned from the system service call.
If memory has been reserved using the Reserved Memory Registry, that memory must be used for the global section named in the SYSMAN command. To return the memory to the system, SYSMAN can be run to free the pre-reserved memory. Once the pre-reserved memory has been freed, the allocate option can no longer be used to create the memory-resident global section.
Shared page tables enable two or more processes to map to the same physical pages without each process incurring the overhead of page table construction, page file accounting, and working set quota accounting. Internally, shared page tables are treated as a special type of global section and are specifically used to map pages that are part of a memory-resident global section. The special global section that provides page table sharing is called a shared page table section. Shared page table sections themselves are memory resident.
6467P001.HTM OSSG Documentation 22-NOV-1996 13:11:56.90
Copyright © Digital Equipment Corporation 1996. All Rights Reserved.