• 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: java.lang.outofmemory
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: java.lang.outofmemory


  • Subject: Re: java.lang.outofmemory
  • From: Art Isbell <email@hidden>
  • Date: Tue, 7 Mar 2006 15:09:17 -1000

On Mar 7, 2006, at 2:49 PM, Denis Stanton wrote:

This has been an interesting discussion as it touches on area that has caused me some grief - outOfMemory problems are hard to solve, partly because they tend to fail to record all the usual evidence.

Possibly one of the reasons this type of problem is difficult to solve is the non-deterministic manner in which Java garbage collects. In the old days (yes, I was there as well :-) when an Objective-C EO was freed, by damn, it was freed :-) None of this waiting around for the JVM to do its cleaning. So you could probably do all the right things programmatically and get nailed because you're fetching more objects before Java has finished cleaning up the old ones. It's probably best to increase the maximum Java heap size as long as doing so doesn't cause paging. Too bad the JVM has to have a maximum Java heap size.


It would really nice if one of you experts could say what combination of saveChanges(), dispose(), invalidateAllObjects(), system.gc() etc is most likely to avoid memory blowout when handling large data volumes, and then if the other experts could voice agreement ?

I'm no expert in Java memory management. Whenever Java throws an out of memory exception, I've just doubled the maximum heap size which has solved the problem. But I'm not fetching huge data sets.


I just have a bias against using invalidateAllObjects() because, for me, it's caused more problems than it's solved. dispose() is invoked automatically, so I don't see a reason to invoke it explicitly. I've read that forcing garbage collection isn't a great idea, so I've never done so. I just use a temporary editing context (don't forget to lock it!) when I'm concerned about memory usage and need to use EO's, and dereference the editing context as soon as I've finished assuming that EOF will take care of freeing snapshots automatically. When I've written utilities that transfer data from one DB to another, I've worked at the EOAdaptor level avoiding EO creation, the overhead of EOControl, etc. Doing so is certainly faster and uses less memory, but isn't convenient if one needs to do some EO processing.

Aloha,
Art

_______________________________________________
Do not post admin requests to the list. They will be ignored.
Webobjects-dev mailing list      (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden


References: 
 >java.lang.outofmemory (From: "Randy Wigginton" <email@hidden>)
 >Re: java.lang.outofmemory (From: Jacky Gagnon <email@hidden>)
 >Re: java.lang.outofmemory (From: Paul Lynch <email@hidden>)
 >Re: java.lang.outofmemory (From: Art Isbell <email@hidden>)
 >Re: java.lang.outofmemory (From: Paul Lynch <email@hidden>)
 >Re: java.lang.outofmemory (From: Art Isbell <email@hidden>)
 >Re: java.lang.outofmemory (From: Denis Stanton <email@hidden>)

  • Prev by Date: Re: java.lang.outofmemory
  • Next by Date: Re: Expanding Import
  • Previous by thread: Re: java.lang.outofmemory
  • Next by thread: Re: java.lang.outofmemory
  • Index(es):
    • Date
    • Thread