• Open Menu Close Menu
  • Apple
  • Shopping Bag
  • Apple
  • Mac
  • iPad
  • iPhone
  • Watch
  • TV
  • Music
  • Support
  • Search apple.com
  • Shopping Bag

Lists

Open Menu Close Menu
  • Terms and Conditions
  • Lists hosted on this site
  • Email the Postmaster
  • Tips for posting to public mailing lists
Re: Memory management
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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.


References: 
 >Memory management (From: "Richard Bruch" <email@hidden>)
 >Re: Memory management (From: Arturo Pérez <email@hidden>)
 >Re: Memory management (From: "Richard Bruch" <email@hidden>)
 >Re: Memory management (From: Arturo Pérez <email@hidden>)
 >Re: Memory management (From: Art Isbell <email@hidden>)

  • Prev by Date: Fwd: WebObjects 5.2.3 is now available
  • Next by Date: Re: WebObjects 5.2.3 is now available
  • Previous by thread: Re: Memory management
  • Next by thread: Re: Memory management (streaming large fetches)
  • Index(es):
    • Date
    • Thread