🚀 go-pugleaf

RetroBBS NetNews Server

Inspired by RockSolid Light RIP Retro Guy

Article View: es.comp.lenguajes.java
Article #28161

Re: A vueltas con el System.gc()

#28161
From: Ignacio Hern�ndez-Ros
Date: Tue, 26 May 1998 00:00
57 lines
3387 bytes

Jos� Manuel L�pez Cobo escribi� en mensaje <896013086.440664@cache>...
>    Y la pregunta es:
>        Alguien sabe como despertar al recolector de basura de W95 ?


Hola Jos� Manuel.

�Con qu� tipo de memoria tienes problemas? Vamos por partes:

El PC dispone de memoria f�sica, Supongamos que tienes 64 Mb de memoria.
El que gestiona esa memoria es el Sistema Operativo que tengas instalado. y
los que demandan la memoria son las aplicaciones. En el caso de Java el que
solicita memoria al sistema operativo SIEMPRE es la m�quina virtual java
(JVM).

C�mo gestiona la JVM las peticiones de memoria hacia el S.O. depende de la
implementaci�n de la JVM, con lo que puedes encontrarte con que jview.exe
funcione completamente distinto que java.exe. Se me ocurre que puede haber
dos maneras de atacar este problema:

a) la JVM al arrancar solicita X Mb de memoria al S.O. los cuales gestiona
ella directamente, cuando la aplicaci�n en JAVA necesita memoria la JVM
entrega memoria de los X Mb entregados por el S.O.
En este caso el gc() es posible que libere memoria llamando a la JVM y esta
a su vez en cualquier momento (sin control por tu parte desde JAVA)
recolecta los huecos de memoria libre cuando le da la gana.

b) Delego las necesidades de memoria de la aplicaci�n en JAVA al S.O. de
manera que cuando la aplicaci�n necesita memoria la JVM la pide al S.O. y
cuando la aplicaci�n libera memoria mediante el GC se produce
(necesariamente) una llamada al S.O. para liberar la memoria solicitada.

En principio da la impresi�n de que (b) puede ser m�s lento que (a) aunque,
dependiendo de c�mo el S.O. gestione la memoria, puede que (b) sea m�s
�ptimo que (a).

Por otro lado est� la memoria que Windows utiliza para sus ventanas, iconos
y controles gr�ficos. Esto es interno de windows y de las llamadas al API de
windows. En este caso la gesti�n de esta memoria no depende de la JVM sino
de c�mo se hacen las llamadas nativas a las apis del S.O. que implementan lo
que quieres hacer en JAVA. Por ejemplo, para pintar un menu en una ventana
hace falta un objeto MenuBar en Java el cual tiene asociado un objeto nativo
del S.O. que representa un men�. En el caso de las clases JAVA de Microsoft
este MenuBar es una barra como las que vienen en el Ofice 97, las cuales son
m�s lentas y consumen m�s recursos que un men� de los antiguos. El mismo
objeto MenuBar que viene en las clases de SUN es un men� m�s feo, aunque un
poco m�s r�pido y que consume menos recursos.

Te aconsejo que optimices tu aplicaci�n en JAVA lo m�s posible, esto har�
que independientemente de la JVM en la que se ejecute se ejecute m�s r�pido.

Pruebes con distintas JVM. Encontrar�s que en cada una de ellas la
aplicaci�n se comporta de forma distinta en cuanto a velocidad y apariencia.

Un saludo!
Technical Details
Message-ID: <6ke1r5$iha$1@talia.mad.ibernet.es>
Path: arc1-ca.pugleaf.net!unknown!not-for-mail
References: <896013086.440664@cache>

Show Full Headers
Complete Article Headers
X-Google-Language: SPANISH,ASCII
X-Google-Thread: 1116f3,e373d29ef3bd7efd
X-Google-Attributes: gid1116f3,public
From: "Ignacio Hern�ndez-Ros" <ihr@recol.es>
Subject: Re: A vueltas con el System.gc()
Date: 1998/05/26
Message-ID: <6ke1r5$iha$1@talia.mad.ibernet.es>
X-Deja-AN: 356576877
References: <896013086.440664@cache>
X-MimeOLE: Produced By Microsoft MimeOLE V4.71.1712.3
Organization: Telefonica Transmision de Datos
Newsgroups: es.comp.lenguajes.java