7.5 The Store structure
7.5.2 Stores
storeType abbreviation
- Specification:
type store- Description:
- An encapsulated type representing store objects.
Datatype
- Specification:
datatype store_status = LOCKED_STATUS | RD_STATUS | WR_STATUS | RDWR_STATUS- Description:
- Each store has a status, which can take the following values:
LOCKED_STATUSStore data may not be accessed or modified by ML.
RD_STATUSStore data is read-only from ML.
WR_STATUSStore data is write-only from ML.
RDWR_STATUSStore data is readable/writeable from ML (the default).
Exception
- Specification:
exception ReadOnly- Description:
- This exception is raised if an attempt is made to write data to a store whose status forbids writing: either
LOCKED_STATUSorRD_STATUS.
Exception
- Specification:
exception WriteOnly- Description:
- This exception is raised if an attempt is made to read data from a store whose status forbids reading: either
LOCKED_STATUSorWR_STATUS.
Function
- Signature:
val storeStatus : store -> store_status- Description:
- Function for inspecting the status of a store object.
Function
- Signature:
val setStoreStatus :
(store * store_status) -> unit- Description:
- Function for setting the status of a store object.
Datatype
- Specification:
datatype alloc_policy =
ORIGIN | SUCC | ALIGNED_4 | ALIGNED_8- Description:
- A store object is created just like any other ML value (except that it is static, that is, the garbage collector may not relocate it) and given some memory for its representation.
- However, a store is involved in managing a number of
objobjects associated with its workspace area. Thealloc_policydatatype is used to specify the manner in which space is given to theseobjobjects from within the store's workspace: ORIGINNewly created objects are initially located at the origin. Once created, such objects may be moved around with their host store by using relocation operations. In this way, you have control of the arrangement of objects within the store.
- Object relocation operations are obviously sensitive to the underlying data model of the foreign language, and so are implemented by the language-specific component of the FI.
SUCCEach fresh object is located at the 'top' of the workspace, immediately following all the other objects.
ALIGNED_4As for
SUCC, but each fresh object is allocated on a 4-byte address boundary (that is, the address is 0 mod 4).ALIGNED_8As for
SUCC, but each fresh object is allocated on a 8-byte address boundary (that is, the address is 0 mod 8).- It is possible to have several stores in use at the same time. Each could have different allocation policies, in order to handle different kinds of data.
Datatype
- Specification:
datatype overflow_policy =
BREAK | EXTEND | RECYCLE- Description:
- Each store object in effect manages a piece of workspace memory on ML's behalf, and objects are associated with parts of this workspace. A store is said to have overflowed when an attempt is made to use more space than is presently available in the associated workspace. When overflow occurs, an overflow policy is enacted. The
overflow_policydatatype provides a number of possibilities when overflow occurs: BREAKThe exception
ExpandStoreis raised upon an attempt to expand the store (possibly made with theexpandfunction, described on page 236). A store with this overflow policy is effectively fixed in size because it cannot be expanded.EXTENDThe store automatically expands, by amount determined by an internal rule, to accommodate further allocation requests. This expansion is obviously subject to system limits on the amount of memory that a process can have mapped at a time.
- Explicit calls to
expand(see page 236) need advice on how much extra space should be allocated. - In effect, stores with this overflow policy are flexible in size and can be expanded as necessary by automatic or manual methods.
RECYCLEAllocation resumes at the origin of the store, overwriting any data presently at the origin. This policy is suitable for stores containing ephemeral objects, that is, objects whose lifetimes are known in advance to be short.
- There is clearly a danger that live data can be overwritten in a store using this policy.
- Stores with this overflow policy may be explicitly expanded. If a request to allocate more space cannot be satisfied for some reason, the
ExpandStoreexception is raised.
Function
- Signature:
val store :
{ alloc : alloc_policy,
overflow : overflow_policy,
status : store_status,
size : int
} -> store- Description:
- This function generates fresh stores. The initial size, allocation policy, overflow policy, and initial store status can be supplied.
- The
store_statusmay be modified using thesetStoreStatusfunction (see page 232), and the store'ssizemay be explicitly increased (when possible) using theexpandfunction (see page 236). The other store attributes cannot be modified dynamically.
Function
- Signature:
val storeSize : store -> int- Description:
- This function returns the current size of the store.
Function
- Signature:
val storeAlloc : store -> alloc_policy- Description:
- This function returns the allocation policy for the store.
Function
- Signature:
val storeOverflow : store -> overflow_policy- Description:
- This function returns the overflow policy for the store.
Function
- Signature:
val isStandardStore : store -> bool- Description:
- This predicate determines if the store is considered to be standard. A store is standard when the allocation policy is not
ORIGINor if the overflow policy is notRECYCLE.
Function
- Signature:
val isEphemeralStore : store -> bool- Description:
- This predicate determines if the store is considered to be ephemeral. A store is ephemeral when the allocation policy is not
ORIGINand the overflow policy isRECYCLE.
Exception
- Specification:
exception ExpandStore- Description:
- This exception is raised when an attempt to expand a store cannot be met.
Function