La única cosa hecha por Off es exportar el hardware presente en la
red, y esto también se aplica en gestión de memoria. El DMM de
Off implementa una TLB software distribuida o DTLB. Una DTLB
es una caché de traducciones de páginas de memoria virtual a marcos de
memoria física distribuida. Su estructura es similar a la de AVM
[61]; el usuario puede establecer traducciones de
memoria virtual a memoria física. La diferencia radica en que las
direcciones de memoria física (como ya vimos al comienzo del capítulo)
no sólo pueden referirse a memoria local sino también a memoria remota
(ver figura 3.26). Esta abstracción es la base para la
implementación de cualquier sistema de memoria virtual distribuido que
emplee el SO que ejecute sobre el 
kernel.
Una DTLB (ver figura 3.26) contiene un conjunto de traducciones de la forma v p:o, donde v es una dirección virtual y p:o es un identificador de marco de página (que como vimos puede corresponder a un marco local o remoto).
La DTLB emplea el hardware de traducción de direcciones como base para su implementación. Las traducciones de la DTLB que tienen como destino un marco de página local (por ejemplo, v1 p:01 en la figura 3.26) tendrán un reflejo en la tabla de páginas empleada por el hardware (v1 m1 en la figura). Las traducciones hacia marcos remotos requieren además de operaciones implementadas en software para su correcto funcionamiento. Aquellas traducciones hacia marcos remotos que estén utilizándose en un instante determinado deberán emplear, naturalmente, marcos locales como cache de los remotos (en la figura, el marco local m3 actúa como cache de q:03, de tal modo que la traducción v3 q:03 de la DTLB tiene como reflejo la traducción v3 m3 en la tabla de páginas.
Figure 3.26: La DTLB. Las traducciones permiten emplear memoria remota.
Dado que las traducciones de que consta la DTLB no emplean identificadores que pudieran perder su significado fuera del nodo local (las direcciones de los marcos son válidas en toda la red) es factible emplear una DTLB dada desde cualquier nodo del sistema. Esto facilitaría la migración de espacios de direcciones construidos sobre las DTLBs de Off.
Las aplicaciones suministran los algoritmos que implementan los protocolos de coherencia y transporte de datos (necesarios para emplear memoria distribuida). En efecto, el DMM se limita a instalar las traducciones y elevar excepciones (mediante upcalls) para requerir la ayuda de la aplicación.
El interfaz suministrado por el DMM es en realidad extremadamente
simple, como puede verse en la figura 3.27 (donde
hemos omitido los puntos de entrada correspondientes a freeze y
melt). En tiempo de creación de la DTLB se establece el
portal al que deben redirigirse las excepciones (upcalls) de la misma,
prtl. Una vez creada, las traducciones se instalan con
dmm_tlb_install y las protecciones se pueden cambiar con
dmm_tlb_prot.
Figure 3.27: Principales puntos de entrada del DMM
A pesar de que la DTLB se inspira en la TLB software de Aegis [60], la implementación ha tomado un camino diferente. En Aegis, una única TLB software (de 1024 entradas) se multiplexa entre las aplicaciones, de tal modo que éstas asignan y liberan entradas de dicha tabla. Esta TLB software emplea la totalidad del hardware de traducción de direcciones, con lo que éste no se multiplexa directamente entre las aplicaciones. El DMM de Off implementa múltiples DTLBs (no una única) que se multiplexan sobre el único hardware de traducción de direcciones disponible. Consiguientemente, una DTLB no se multiplexa en realidad; cada aplicación posee la suya propia.
Las razón principal que nos llevó a optar por múltiples DTLBs multiplexadas sobre el hardware (y no a una única multiplexada entre las aplicaciones) fue la consideración de arquitecturas con tablas de páginas. En Aegis la implementación se efectuó sobre el procesador MIPS, que sólo dispone de TLB (su hardware no utiliza tablas de páginas, siendo éstas gestionadas mediante software). Esta TLB emplea identificadores de contexto de tal modo que es posible seleccionar fácilmente las entradas que corresponden a una aplicación determinada, resultando trivial su multiplexación.
Si consideramos ahora arquitecturas con tablas de páginas, resulta más simple emplear una tabla de páginas para cada aplicación que multiplexar una única tabla de páginas entre distintas aplicaciones. Ésto ha determinado el empleo de múltiples DTLBs.