This memory link probably would not have occurred if you had used Ada. Many 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]
