On Mon, 14 Jun 2010 13:04:05 +0300, Georg Datterl
<[email protected]> wrote:
Let's blame java:
http://java.sun.com/javase/technologies/hotspot/gc/gc_tuning_6.html#par_gc.oom
Thanks for the link. I already knew what this exception results from but
what baffles me is that how the runtime profile can be so different for 32
and 64-bit jvms for the same application + the same input data. The 32-bit
process being able to complete with -Xmx500m and 64-bit jvm still failing
with -Xmx1000m seems to indicate that the program, when run 64-bit, is
keeping references to lots more data than the 32-bit version. Jvm being
stuck in gc so that > 98% of the time is spent in gc and no (significant
amount of) memory is freed indicates either that the app is keeping
references to large amounts of data or GC can't reclaim memory due to a
jvm bug. The latter is possible but the former is much more common.
Anyone else run into this issue with FOP or any other Java program? I
don't mean just the GC overhead limit exceeded, but this kind of
difference in results with 32- and 64-bit jvms.
::Antti::
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
