6.6 Memory Object Attributes

Function: kern_return_t memory_object_get_attributes (memory_object_control_t memory_control, boolean_t *object_ready, boolean_t *may_cache_object, memory_object_copy_strategy_t *copy_strategy)

The function memory_object_get_attribute retrieves the current attributes associated with the memory object.

The argument memory_control is the port, provided by the kernel in a memory_object_init call, to which cache management requests may be issued. If object_ready is set, the kernel may issue new data and unlock requests on the associated memory object. If may_cache_object is set, the kernel may keep data associated with this memory object, even after virtual memory references to it are gone. copy_strategy tells how the kernel should copy regions of the associated memory object.

This routine does not receive a reply message (and consequently has no return value), so only message transmission errors apply.

Function: kern_return_t memory_object_change_attributes (memory_object_control_t memory_control, boolean_t may_cache_object, memory_object_copy_strategy_t copy_strategy, mach_port_t reply_to)

The function memory_object_change_attribute sets performance-related attributes for the specified memory object. If the caching attribute is asserted, the kernel is permitted (and encouraged) to maintain cached data for this memory object even after no virtual address space contains this data.

There are three possible caching strategies: MEMORY_OBJECT_COPY_NONE which specifies that nothing special should be done when data in the object is copied; MEMORY_OBJECT_COPY_CALL which specifies that the memory manager should be notified via a memory_object_copy call before any part of the object is copied; and MEMORY_OBJECT_COPY_DELAY which guarantees that the memory manager does not externally modify the data so that the kernel can use its normal copy-on-write algorithms. MEMORY_OBJECT_COPY_DELAY is the strategy most commonly used.

The argument memory_control is the port, provided by the kernel in a memory_object_init call, to which cache management requests may be issued. If may_cache_object is set, the kernel may keep data associated with this memory object, even after virtual memory references to it are gone. copy_strategy tells how the kernel should copy regions of the associated memory object. reply_to is a port on which a memory_object_change_completed call will be issued upon completion of the attribute change, or MACH_PORT_NULL if no acknowledgement is desired.

This routine does not receive a reply message (and consequently has no return value), so only message transmission errors apply.

Function: kern_return_t memory_object_change_completed (memory_object_t memory_object, boolean_t may_cache_object, memory_object_copy_strategy_t copy_strategy)

Function: kern_return_t seqnos_memory_object_change_completed (memory_object_t memory_object, mach_port_seqno_t seqno, boolean_t may_cache_object, memory_object_copy_strategy_t copy_strategy)

The function memory_object_change_completed indicates the completion of an attribute change call.

The following interface is obsoleted by memory_object_ready and memory_object_change_attributes. If the old form memory_object_set_attributes is used to make a memory object ready, the kernel will write back data using the old memory_object_data_write interface rather than memory_object_data_return..

Function: kern_return_t memory_object_set_attributes (memory_object_control_t memory_control, boolean object_ready, boolean_t may_cache_object, memory_object_copy_strategy_t copy_strategy)

The function memory_object_set_attribute controls how the memory object. The kernel will only make data or unlock requests when the ready attribute is asserted. If the caching attribute is asserted, the kernel is permitted (and encouraged) to maintain cached data for this memory object even after no virtual address space contains this data.

There are three possible caching strategies: MEMORY_OBJECT_COPY_NONE which specifies that nothing special should be done when data in the object is copied; MEMORY_OBJECT_COPY_CALL which specifies that the memory manager should be notified via a memory_object_copy call before any part of the object is copied; and MEMORY_OBJECT_COPY_DELAY which guarantees that the memory manager does not externally modify the data so that the kernel can use its normal copy-on-write algorithms. MEMORY_OBJECT_COPY_DELAY is the strategy most commonly used.

The argument memory_control is the port, provided by the kernel in a memory_object_init call, to which cache management requests may be issued. If object_ready is set, the kernel may issue new data and unlock requests on the associated memory object. If may_cache_object is set, the kernel may keep data associated with this memory object, even after virtual memory references to it are gone. copy_strategy tells how the kernel should copy regions of the associated memory object.

This routine does not receive a reply message (and consequently has no return value), so only message transmission errors apply.