Most memory leaks are the result of using pointers. If a language provides a construct that can replace the use of pointers, then this problem can be minimized. Java has significant overhead because it checks its dispatching at run-time rather than at compile time. Bob Leif Robert C. Leif, Ph.D. Email [EMAIL PROTECTED]
-----Original Message----- From: Ben Galbraith [mailto:[EMAIL PROTECTED] Sent: Tuesday, September 16, 2003 8:22 AM To: [EMAIL PROTECTED] Subject: Re: Memory consumption Robert C. Leif wrote: > This memory link probably would not have occurred if you had used Ada. Many If *I* had used Ada? :-) I've contributed 0.00001% of the FOP code (a measly patch for CMYK images); don't look @ me! Let's not get into debates about "superior languages"; I think time has shown the topic to be a morass of flame wars and pointless arguments. As far as memory leaks go, the notion of a program continuing to reference memory unnecessarily is fairly language agnostic. Ben > of the items that Java internally represents as pointers can be coded as Ada > generics (templates), which incidentally can be combined with tagged types > (classes)to provide a very flexible form of inheritance. Java is still not > portable, since it requires its own environment and is not an ISO standard. > Ada is an ISO standard. Even C# would have been a better choice; at least it > is an ECMA standard and has a decent execution speed. > Bob Leif > Robert C. Leif, Ph.D. > Email [EMAIL PROTECTED] > > -----Original Message----- > From: Ben Galbraith [mailto:[EMAIL PROTECTED] > Sent: Tuesday, September 16, 2003 7:28 AM > To: [EMAIL PROTECTED] > Subject: Re: Memory consumption > > Folks, > > If you haven't figured it out yet, let me inform you: FOP suffers from > large memory leaks. A memory leak in Java is nothing mysterious; it > occurs because a program never dereferences objects, which prevents the > Java garbage collector thread from reclaiming them. Thus, no matter how > many times you try to tell the GC thread to collect (with System.gc() > and other nonsense) the memory will never be reclaimed. > > There are only two solutions: > > 1. Split up FOP generation into discreet jobs, and spawn a new JVM to > generate each job. You can get fancy and create a system that uses a > spawned JVM until it runs out of memory -- use the Runtime objects > memory methods to check. > > 2. Fix FOP's memory leak problem. > > I've had this on my to-do list to patch in maintenance for some time, > but frankly, for me it was much cheaper to distribute FOP jobs across > our network in parallel jobs running on multiple JVMs. Parallel > computing, baby. > > Ben > > Ganesh wrote: > >>If you can afford the gc time consumption then there is a sure way of >>garbage collection. This method will ensure that garbage is collected >>for sure...Use the "Sizeof" class as given in the java world article >>below. This is a sure way of garbage collection, but then it slows down >>the system ! >> >>http://www.javaworld.com/javaworld/javatips/jw-javatip130.html >> >> >> >> >> >>-----Original Message----- >>From: Dennis Myrén [mailto:[EMAIL PROTECTED] >>Sent: Tuesday, September 16, 2003 7:12 PM >>To: [EMAIL PROTECTED] >>Subject: RE: Memory consumption >> >> >>I am not an expert in java memory handling either, >>But I suggest you release all handles after each run in the loop, And >>then perform a garbage collect. >> >> >>Regards, >>dennis.myren >> >>-----Original Message----- >>From: Timo Haberkern [mailto:[EMAIL PROTECTED] >>Sent: 16. september 2003 15:38 >>To: [EMAIL PROTECTED] >> >> >> >> >>><snip/> >>> >>>I'm not really the expert on JVM Memory Management, but AFAICT these >>>declarations belong outside the 'for'-loop. (Not sure whether this is >>>causing memory problems, but it just seems ... more elegant. If they >>>really do not depend on the variables changing in the loop, that is... >>>If behaviour would be what I'm guessing, then these would consume >>>memory - the total of which would only be released on completion of the >> >> >>>loop...) >>> >>><snip/> >>> >>No :-( That doesn't help anything... >> >>Any other ideas? >> >> >> >>>> driver = null; >>>> >>>> >>> >>>You won't be needing this. Just resetting the Driver should be ok. >>> >>> >> >>mhmm, that was i try! I thought that it maybe helps a little bit but it >>doesn't. But it remains anyhow... >> >> >> >>>I also notice you have read this (?) >>>http://xml.apache.org/fop/running.html#memory >>> >>>Have you tried the multiple page-sequences tip? >>> >> >>Every PDF File is only 2 pages long. And the memory is consumed for PDFs >> >>with big images... >> >>My problem is that i can't get down the memory after rendering one PDF >>and before the next rendering... >> >>regds >> >>Timo >> >> >>--------------------------------------------------------------------- >>To unsubscribe, e-mail: [EMAIL PROTECTED] >>For additional commands, e-mail: [EMAIL PROTECTED] >> >> >> >> >>--------------------------------------------------------------------- >>To unsubscribe, e-mail: [EMAIL PROTECTED] >>For additional commands, e-mail: [EMAIL PROTECTED] >> >> >>**************************Disclaimer************************************ >> >>Information contained in this E-MAIL being proprietary to Wipro Limited is > > >>'privileged' and 'confidential' and intended for use only by the > > individual > >> or entity to which it is addressed. You are notified that any use, > > copying > >>or dissemination of the information contained in the E-MAIL in any manner >>whatsoever is strictly prohibited. >> >> > > *************************************************************************** > >>--------------------------------------------------------------------- >>To unsubscribe, e-mail: [EMAIL PROTECTED] >>For additional commands, e-mail: [EMAIL PROTECTED] >> >> > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
