Article View: es.comp.lenguajes.java
Article #28161Re: A vueltas con el System.gc()
From: Ignacio Hern�ndez-Ros
Date: Tue, 26 May 1998 00:00
Date: Tue, 26 May 1998 00:00
57 lines
3387 bytes
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-mailReferences:
<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