Asignación de memoria a gvSIG

En los últimos días han vuelto a aparecer por las listas de usuarios de gvSIG mensajes preguntando como y hasta cuanto se puede aumentar la memoria que se reserva gvSIG al arrancar en entornos Microsoft. Independientemente de en que fichero se especifique esto, una tema que sorprende a los usuarios es…

«¿si mi sistema tiene 4Gb de RAM (o más) cómo puede quedarse sin memoria gvSIG?»

El problema viene derivado de que gvSIG es una aplicación de 32bits. Esto quiere decir que por limitaciones de arquitectura de la CPU para la que ha sido desarrollada solo es capaz de acceder a 2^32 bits que son los 4Gb de memoria que puede direccionar un sistema Microsoft de 32 bits. Con esto ya tenemos nuestra primera limitación. En un sistema Microsoft de 32 bits no podremos tener más de 4Gb de RAM, y aunque nuestra máquina tenga más de 4 Gb, el sistema no los reconocerá.

De esos 4 Gb de RAM que puede tener nuestro sistema de 32 bits, el sistema se reserva unos cuantos para diversos usos, por ejemplo: muchas tarjetas gráficas actuales, en lugar de llevar su propia memoria usan parte de la memoria del sistema, así que si la tarjeta de vídeo usa de 512Mb a 1024Mb tendremos que de nuestros 4Gb nos quedaremos solo con 3Gb. Además si tenemos otros dispositivos instalados en el equipo que precisan reservarse parte de la memoria, también los cogerán de esos 4Gb que tenemos, y el propio sistema también precisa usar parte de esa memoria para sus propias tareas, con lo que nos quedaran de 2Gb a 3Gb libres para nuestra aplicación. Sin embargo, parece ser que el sistema solo asigna a las aplicaciones de 32 bits un máximo de 2Gb. Pero de esos 2Gb que pueden ser asignados a nuestra aplicación tampoco podemos asumir que todos los podemos asignar a gvSIG… directamente. En esos 2Gb estará la maquina virtual de java, los recursos java que componen nuestra aplicación, y las librerías nativas y la memoria que estas puedan necesitar. En generan de esos 2Gb, podremos reservar para nuestra aplicación java hasta 1600Mb, ya que el resto lo necesitaremos para la máquina virtual y las librerías nativas, pero si apuramos tanto podemos encontrarnos que en caso de que alguna de las librerías nativas precisen reservar memoria falle la aplicación. así que mejor ser algo conservador y no asignar a nuestra aplicación más de 1400Mb.

Resumiendo… en un sistema Microsoft de 32 bits no podremos asignar a nuestra aplicación java más de 1408Mb aproximadamente.

Y la siguiente pregunta que nos podemos hacer es… Y si tengo un sistema Microsoft con por ejemplo 8Gb ¿puedo tener más memoria en gvSIG?

Pues aunque sea un sistema de 64 bits, y desaparezca la limitación de los 4Gb de RAM, con gvSIG estaremos igual que con un sistema de 32 bits, ya que al no estar preparada la aplicación gvSIG para soportar sistemas de 64 bits, el sistema operativo la ejecuta en modo emulación de 32 bits, estando sujetos a las limitaciones de las aplicaciones de 32 bits.

En gvSIG 2.1 se puede cambiar la memoria desde las Preferencias de la aplicación.

00_memoria

En gvSIG 2.0 si queremos personalizar la memoria que dejamos para nuestra aplicación tendremos que editar el fichero “gvsig-desktop.l4j.ini” que se encuentra en la carpeta en la que hayamos instalado gvSIG. En el nos encontraremos algo como

###############################
# gvSIG runtime configuration #
###############################

# Starting memory
# -Xms128m

# Maximum memory
# -Xmx512m

# Maximum perm space size
# -XX:MaxPermSize=96m

# Disable hardware accelerated java2D drawing through Direct3D 
# -Dsun.java2d.d3d=false

# For Java parameters documentation and more parameters look at:
# http://download.oracle.com/javase/6/docs/technotes/tools/windows/java.html
# http://www.oracle.com/technetwork/java/javase/tech/vmoptions-jsp-140102.html

# Environment variable expansion is supported, for example:
#-Dsomevar="%SOMEVAR%"

Un valor aceptable para la cantidad máxima de memoria que le damos a la aplicación estará entre 1256Mb y 1408Mb. Para asignarlo modificaremos las lineas:

# Maximum memory
-Xmx1408m

Espero que haya servido esta pequeña explicación.

Un saludo
Joaquin

About Joaquin del Cerro

Development and software arquitecture manager at gvSIG Team. gvSIG Association
This entry was posted in gvSIG Desktop, spanish and tagged , . Bookmark the permalink.

6 Responses to Asignación de memoria a gvSIG

  1. Ignasi Ferrer Giró says:

    Gracias por la explicación y por aclarar el tema del manejo de la memória. Ahora bien, para un sistema con 4 Gb de memória, Que valores son aconsejables para -Xms y -XX:MaxPermSize?

    • Joaquin del Cerro says:

      Hola Ignasi.
      El valor de Xms es la cantidad de memoria que se le asigna a la maquina virtual de java en el momento de arranque de esta. Sirve para que si sabemos que la aplicación va a consumir X de memoria, en lugar de que esta los vaya pidiendo conforme los necesite, se reserven en el momento del arranque. Este valor esta mas ligado a la propia aplicación que a la memoria que tenga el sistema, y los valores por defecto en gvSIG suelen ser adecuados. Si la aplicación requiere mas memoria que la indicada aquí, la ira pidiendo hasta llegar al limite indicado en Xmx. Hay que tener en cuenta que puede llegar a ser contraproducente asignar en el Xms un valor alto si no va a ser necesario, ya que en un sistema de 32bits estarás pidiendo memoria innecesariamente que otras aplicación pueden necesitar.

      Respecto al valor del MaxPermSize, esta relacionado con la cantidad de clases java y de sus atributos y métodos, de forma que para una aplicación la cantidad necesaria de memoria en esta área es mas o menos constante. Los valores que tiene asignado gvSIG por defecto son adecuados para una versión “standard”, y solo si incluyese bastantes plugins extra podría darse el caso de que necesitase mas memoria para esta área.

      En general, mi recomendación es que para un gvSIG 2.0 los valores que trae por defecto para ambos parámetros serán adecuados ya que estos no dependen de la cantidad de memoria que tenga tu sistema.

      Un saludo
      Joaquin

  2. Pingback: Problemas con las rutas al abrir proyectos gvSIG

  3. Buenas tardes,
    He encontrado ese archivo y he intentado asignarle más memoria, pero al cerrar el archivo me dice ACCESO DENEGADO y no me deja realizar cambios, a pesar de ser el administrador.
    ¿cómo puedo salvar este problema?
    Saludos y gracias
    María

  4. aly says:

    Necesitas darle permiso de escritura al archivo .ini y con eso ya se puede modificar

  5. Pingback: gvSIG 2.1: Gestión de memoria | gvSIG blog

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s