Robert,
Robert C. Leif wrote:
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.
As you may know, there are two types of memory leaks: "physical leaks" resulting from bad pointer handling, and "logical leaks" which occur as described below -- when a program holds on to data longer than it should. The classic Java example is the Map-based cache that grows forever.
Java's GC automatically handles the classic pointer-related memory leaks; the "logical leaks" are nastier beasts to track down and require some sort of memory heap snapshot or real-time profiler. Ada, C, C++, C#, VB, Perl, Python, etc. are all susceptible to this type of memory leak, just as each of those languages are capable of storing information in arrays or array-like structures.
Sadly, our FOP also suffers from one or more logical memory leaks. Tracking it down really shouldn't be that hard; someone just needs to use the JDK profiling tools, a third-party tool, or their eyes to track down where FOP isn't dereferencing the appropriate objects. It may very well be that a List or Map is hanging around someplace.
Ben
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]
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
