[olug] Re: OJUG Re: Commanding java_vm to give memory back to the OS?

Rob Townley rob.townley at gmail.com
Sat Jan 28 20:55:51 UTC 2006


This link should take  you to a java version verification applet at
BroadBandReports.com.  All it does is tell you which version of java
you are using.
http://www.dslreports.com/speedtest?test=1
This uses the applet tag and i do not see any parameter that would set
270M.  If you try this applet, please let me know the memory results.

I was wondering about OpenOffice myself because at times it was
running at the same time.  However, In the KDE process tree, the
java_vm is listed as a branch under firefox.  The java_vm does not
appear to start until i tell firefox to goto the java verification
applet mentioned above.  I do not believe the OO quickstart app is
running.

Maybe firefox passes its own parameters?

On 1/28/06, Matt Morton <matt.g.morton at gmail.com> wrote:
>
> Exactly what application is running?  It sounds like from your post
> that you don't know which app is invoking the jvm?  If so then check
> to see if OpenOffice 2.0 quickstart app is running.  It uses HSQLDB
> as its Access clone, maybe that is what is using the jvm?
>
> Otherwise look for a process that might spawn another process and
> then the parent dies off (Apache does this) leaving child processes
> running.
>
> When I have used the command line parameters below they have always
> worked.  I have not used them with the JRE though.
>
> Matt Morton
>
>
> On Jan 28, 2006, at 11:42 AM, Rob Townley wrote:
>
> >
> > Matt,
> >
> > thanks for the Xms tip, after doing various searches for Xms, i also
> > found Xmx, which sets the maximum size.  I tried setting the following
> > "-Xms8M -Xmx64M" parameters in the ./ControlPanel, thinking this would
> > set the minimum size to 8M and the max to 64M.  I rebooted.  The
> > java_vm memory usage has not changed, still using 270MB.
> >
> > JRE   1.5.0_06        /usr/lib/j2se/jre1.5.0_06       -Xms8M -Xmx64M
> >
> > I guess the next step is to figure out how to prints out the command
> > line parameters to verify whether or not the XMS and XMX parameters
> > are actually seen.
> >
> >
> > On 1/25/06, Matt Secoske <secoskem at gmail.com> wrote:
> >> To see what the JVM thinks is free or total memory, look at the
> >> java.lang.Runtime javadocs  for the freeMemory() and totalMemory()
> >> methods.
> >> The only thing you can do to free up memory is to call Runtime.gc().
> >> Unfortunately this will run at its discretion, and may or maynot (or
> >> both!!!) free up memory.
> >>
> >> You may also want to lower the minimum amount of memory the JVM
> >> holds: when
> >> starting the JVM pass it the -XMS parameter with a value of, say
> >> 16M (for 16
> >> megabytes).  (i.e.  java -XMS16M matt.MyClass)
> >>
> >> There are some other command line options to reduce memory/control
> >> the
> >> garbage collector... overall its best to leave those alone unless
> >> you know
> >> exactly what you are doing.
> >>
> >> - Matt
> >>
> >> On 1/25/06, Rob Townley <rob.townley at gmail.com> wrote:
> >>>
> >>>    According to the "KDE System Guard" process list, my java_vm is
> >>> using 276MegaBytes of memory.  I only have 256MB of physical ram, so
> >>> my harddrive is swapping like crazy and wasting battery life.  I
> >>> opened the java console and ran garbage collection, but the console
> >>> says java is using less than 4MB of RAM.   I know for certain, that
> >>> there are no Java applets running, so it should be using zero.  How
> >>> can i command JAVA to give the memory back to the operating system
> >>> that it is not using?
> >>>
> >>>   At one time, there was NOT a standard C function to actually tell
> >>> the C runtime to give the memory back to the OS.  The C runtime
> >>> would
> >>> keep the memory even though you had freed it.  But some operating
> >>> systems have a  non standard call to free the memory.
> >>>
> >>> 256MB RAM
> >>> Java 1.5
> >>> FireFox 1.5
> >>> Debian Linux with 2.6 Kernel
> >>>
> >>
> >>
> >>
> >> --
> >> Matt Secoske
> >>  http://www.secosoft.net
>
>



More information about the OLUG mailing list