Dado que el DMM opera con direcciones de marcos que no tienen porqué ser locales, podemos emplear memoria remota en nuestras traducciones. En este sentido, hay algunas implicaciones que resultan importantes para la implementación de cualquier sistema que emplee la DTLB.
En primer lugar, cualquier entidad que implemente el interfaz de un gestor de memoria física puede suministrar marcos de memoria que pueden luego emplearse como destino de las traducciones de una DTLB. Téngase en cuenta que el usuario del sistema solicita la asignación de marcos y emplea los identificadores de éstos para la instalación de traducciones en su DTLB. Todo lo que el DMM necesita para instalar una traducción en una DTLB es la dirección de la página que se traduce (ej.: v3) y el identificador del marco al que se traduce (ej.: q:o3). Dado que el identificador de un marco de página contiene el identificador de portal del gestor de memoria física donde está ubicado (ej.: q), el DMM tiene toda la información necesaria para gestionar la traducción.
Cuando se instala una traducción de una página a un marco remoto y se referencia dicha página, el DMM eleva una excepción (mediante un upcall al portal de excepciones indicado por la DTLB). El propósito de dicha excepción es requerir del usuario la copia del marco remoto en el nodo local. El DMM indica el origen y destino de la traducción considerada y se espera que el usuario indique cual es el marco local que debe emplearse como cache del remoto. Las aplicaciones pueden escoger entre emplear gestores de memoria virtual distribuida de propósito general (estableciendo el portal de alguno de ellos como portal de excepción de la DTLB) o emplear sus propios gestores de memoria virtual distribuida.
En segundo lugar, Off no emplea revocación implícita (de hecho Off no revoca recursos como vimos en el capítulo anterior), con lo que las aplicaciones tienen más oportunidades para controlar la asignación y revocación de sus marcos. Concretamente, Off no revoca derechos sobre marcos de página a las aplicaciones, esto es tarea del SO implementado sobre Off. Las aplicaciones pueden escoger los marcos que deben liberar (bajo la supervisión de un árbitro como vimos en el apartado 2.1.5).
Por todo lo dicho, es posible operar con memoria local, memoria remota, memoria procedente de disco y memoria cuyo contenido se construye en demanda de un modo homogéneo, con lo que se simplifica la realización de sistemas de memoria virtual en área de aplicación. En los apartados que siguen veremos algunos ejemplos.