El efecto 2038

Ya queda un poco lejano el efecto 2000, pero afortunadamente para nuestras espectativas de trabajo se acerca el efecto 2038. Este futuro efecto está causado por la longitud del espacio reservado para almacenar timestamps en POSIX (time_t es un entero de 32 bits con signo) que cuenta el número de segundos transcurridos desde el 1/Ene/1970 a las 00:00:00 y alcanza su valor máximo (19/Ene/2038 a las 03:14:07), comenzando de nuevo la cuenta por el 1/Ene/1970. En arquitecturas de 64bits, time_t usa un entero con signo, pero de 64bits, que aplaza el problema durante unos cuantos millones de años, y claro, si el estándar POSIX ha funcionado bien durante todos estos años, tampoco íbamos a modificarlo para corregir este inconveniente, y por supuesto, tampoco es necesario montar sistemas que sabemos en el año 2038 tendrán problemas con la hora: Es deseable que los administradores Unix comencemos a migrar nuestros sistemas de 32 a 64 bits, por el llamado efecto 2038.
Una vez se dispone de una plataforma 64bits, es deseable usar una ver- sión Java de 64bits. La versión de 32bits de Java en Linux, tiene la gran limitación de permitir asignar hasta 3GB de RAM para la máquina virtual, y de ellos, sólo podremos darle a nuestra aplicación 2GB, porque el restante lo necesita la Runtime de Java para alojar el recolector de basura, heap, PermGen, etc. Esto que parece mucho, en realidad conforme van subiendo las conexiones a nuestro servidor se convierte en un inconveniente, porque la única forma que tenemos de mejorar el tiempo de respuesta y la cantidad de threads es aumentando la asignación de memoria RAM a la máquina virtual. Las distintas librerías y frameworks que actualmente necesitan las aplicaciones Java hacen que 2GB de RAM sea poco a largo plazo, y claro, no está recomendado si vamos a poner en marcha un sistema con la previsión de que esté funcionando después del año 2038.

La imagen la he sacado del album de simpologist en flickr