Re: Memory management
Re: Memory management
- Subject: Re: Memory management
- From: Rob Lockstone <email@hidden>
- Date: Tue, 16 Mar 2004 14:50:03 -0800
On Mar 16, 2004, at 14:10, Art Isbell wrote:
Yes. There should be no EO's, no snapshots, just one "row"
NSDictionary and one "res" object. Each of these should lose its
reference with each loop so all but the current values should be
available for Java garbage collecting. I guess I would try explicitly
setting each to null at the end of each loop in hopes that the garbage
collector would notice. But if that fails, I'd probably try forcing
garbage collecting by invoking System.gc() periodically (e.g., every
100 iterations??) at the end of the loop.
Just for correctness's sake, System.gc() doesn't actually "force" gc to
take place. It basically tells the JVM, "Please try to run the gc if
you can. Thanks." Having said that, it pretty much always does cause
the gc to run.
Now, it gets even a little more complicated. What I'm about to say is
pretty high level, so please don't ding me on specifics. :-) Assuming
you're running the default GC (there are several options) which is a
generational collector, there are essentially two garbage collectors.
One is a lightweight collector which runs quite often and is very
quick. It's basically responsible for cleaning up short-lived objects
which reside in the "eden" or "young" generation. Objects which hang
around past a certain threshold get promoted to the "old" generation
(technically, there can be several stages of "old" generations). The
other collector is responsible for cleaning up everything, including
items in the older generations. Depending on how big your heap is, how
fast your machine is, and how many objects are currently in memory, it
can take several seconds to run, during which time the world stops,
i.e. all threads are suspended (except the gc thread of course) and
nothing gets executed. This so-called "Full GC" is what you're asking
the JVM to do when you call System.gc(). Usually, it's not a good idea
to explicitly request full gc's unless you really know what you're
doing and you don't mind having the JVM stop everything for several
seconds at a time as it traverses the entire heap looking for garbage.
In general, garbage collection "just works". If you have dead objects,
they'll get cleaned up in due course when required.
If you're creating lots and lots of short-lived objects, what you
probably want to do is fiddle with the heap settings, especially with
the size of the eden partition (usually controlled via the -Xmn
parameter). If you have a very small eden, and you're creating lots of
objects, the gc has to spend a lot more time either traversing the eden
partition to remove these objects, or potentially promoting them to an
older generation when it's not really necessary. Tuning your heap sizes
can have a profound impact on performance. Here's a couple articles you
might want to read. I actually haven't read about this since 1.3, so my
information above might be slightly out-of-date if they've changed
things drastically wrt garbage collections, but I don't *think* they
have.
http://java.sun.com/docs/hotspot/gc1.4.2/index.html (specific to 1.4.2,
so very good info here)
http://java.sun.com/docs/hotspot/ (general list of good things to know)
http://java.sun.com/developer/technicalArticles/ALT/RefObj/ (this one's
kinda old, but interesting)
You also might want to enable gc logging via -Xloggc:gc.log. That will
cause a file named gc.log to be created which will show you when, how
long, and how much memory was reclaimed, by the gc. Note that Full GC's
are denoted by the word "Full".
Hope this helps out.
Rob
_______________________________________________
webobjects-dev mailing list | email@hidden
Help/Unsubscribe/Archives: http://www.lists.apple.com/mailman/listinfo/webobjects-dev
Do not post admin requests to the list. They will be ignored.