(v13) Harlequin RIP memory models

This page applies to Harlequin v13.1r0 and later; and to Harlequin Core but not Harlequin MultiRIP.

The Harlequin RIP core library used by Harlequin Core may be configured to interact with the operating system in a two of different ways:

• The MPS may be configured to sub-allocate memory for the RIP from a single, fixed block of memory provided by your integration. This method is generally appropriate for embedded systems where virtual memory is not present; where the RIP is one of a set of known processes running on the device; and for applications where having a fixed amount of physical memory dedicated to just the RIP is an advantage.
• The MPS may be configured to reserve a range of address space, and then map and unmap physical memory pages from the operating system into that address space. This method is generally appropriate for server and desktop operating systems that support virtual memory, and for integrations that use multiple RIP or other workflow processes on the same machine. The RIP allocates memory through the MPS; the MPS places the RIP's allocations into pools , consisting of a number of memory segments. The MPS maps physical memory pages into the virtual address space as the RIP's memory demands increase, and it also releases unused segments back to the operating system as the memory demands of the RIP reduce.

While it is theoretically possible to create a new MPS arena type to implement interactions with the operating system other than those above, Global Graphics does not recommend this. If a behavior other than the two methods above is required, you should contact Global Graphics about your requirements.