On Dec 5, 2007, at 15:23, Chris Bowditch wrote:
Andreas L Delmelle wrote:
On Nov 27, 2007, at 20:06, Andreas L Delmelle wrote:
Hi Andreas,
snip/
I tested on Apple JVM 1.4.2 and 1.5.0 on OS X 10.4. Both
single- and multi-threaded.
Heap remains stable here over hundreds of runs.
With
On Nov 27, 2007, at 20:06, Andreas L Delmelle wrote:
Hi Chris (and other interested parties)
On Nov 27, 2007, at 18:32, Chris Bowditch wrote:
Andreas L Delmelle wrote:
Cannot reproduce it here...
Strange. The patch is definitely applied and I tried building it
twice just to make sure.
On Nov 26, 2007, at 12:48, Chris Bowditch wrote:
Hi Chris
Andreas L Delmelle wrote:
Made yet another attempt to simplify/correct the design a bit
(and hopefully fix the leak as well).
Thanks for taking the time to revisit this problem :)
Although I noticed that the diff appears to be
Andreas L Delmelle wrote:
snip/
Sorry, hadn't updated for over a week... :/
No problem. It was easy enough to revert to the previous revision.
snip/
Ouch! I wasn't using the right expression to map from the stale entry's
hashCode to the corresponding bucket index.
Fixed in the diff in
On Nov 27, 2007, at 18:04, Chris Bowditch wrote:
Andreas L Delmelle wrote:
snip/
Sorry, hadn't updated for over a week... :/
No problem. It was easy enough to revert to the previous revision.
snip/
Ouch! I wasn't using the right expression to map from the stale
entry's hashCode to the
Andreas L Delmelle wrote:
On Nov 20, 2007, at 17:53, Chris Bowditch wrote:
Hi Chris
Hi Andreas,
Made yet another attempt to simplify/correct the design a bit (and
hopefully fix the leak as well).
Thanks for taking the time to revisit this problem :)
Although I noticed that the
On Nov 20, 2007, at 17:53, Chris Bowditch wrote:
Hi Chris
Chris Bowditch wrote:
snip/
Tested it here, and I don't see any immediate leakage anymore.
One 71-page document, and with -Xmx256M, the heap never exceeded
+/-85M. Each document rendered consistently within 3-4s (ran up
to
Chris Bowditch wrote:
snip/
Tested it here, and I don't see any immediate leakage anymore.
One 71-page document, and with -Xmx256M, the heap never exceeded
+/-85M. Each document rendered consistently within 3-4s (ran up to
1000 subsequent renderings).
Well memory seems okay for the
Andreas L Delmelle wrote:
Hi Andreas,
On Nov 16, 2007, at 17:38, Chris Bowditch wrote:
snip /
Both the 'theoretical limit' issue and the 'too many threads'
should be resolved.
No OOM Error yet, but I'm sure it can't be far away. I just wanted to
update you before I go offline for
On Nov 16, 2007, at 17:38, Chris Bowditch wrote:
snip /
Both the 'theoretical limit' issue and the 'too many threads'
should be resolved.
Great :) Although whilst testing your latest patch the memory leak
seems to be back :(
The test has been running for a few hours now and progressing
Andreas L Delmelle wrote:
On Nov 15, 2007, at 16:30, Chris Bowditch wrote:
Thanks for the diff. Unfortunately I have been unsuccessful in
applying it after several attempts. First I tried using Tortoise SVN
client, then I downloaded GNUWin32 Patch and that fails to apply all
but hunk
Sounds pretty good. About the potential issue you described: Writing
unit tests for the class can help you a long way catching potential
problems early. Might actually be worth it considering such a critical
components in the FO tree area. Just a thought.
Jeremias Maerki
On 15.11.2007 01:18:32
Jeremias Maerki wrote:
The attached patch should fix the memory leak Chris described (in one of
my runs the number of CacheEntry instances after a full GC went down
from 10575 (169KB, before the change) to 386 (6KB, after the change).
I've run various documents through the multi-threading
On Nov 15, 2007, at 16:30, Chris Bowditch wrote:
What I see as a possible issue though, is that there is a
theoretical limit to rehash() having any effect whatsoever. If
the cache grows to 64 buckets, then the maximum number of
segments that exceed the threshold can never be greater
Andreas L Delmelle wrote:
On Nov 14, 2007, at 21:38, Jeremias Maerki wrote:
Hi Jeremias, Chris,
jm-PropertyCache-MemLeak.diff.txt
My proposal, incorporating the changes in Jeremias' diff, below.
Thanks for the diff. Unfortunately I have been unsuccessful in applying
it after several
On Nov 15, 2007, at 16:30, Chris Bowditch wrote:
Thanks for the diff. Unfortunately I have been unsuccessful in
applying it after several attempts. First I tried using Tortoise
SVN client, then I downloaded GNUWin32 Patch and that fails to
apply all but hunk 7. I also asked a colleague
Andreas L Delmelle wrote:
Hi Andreas,
A splendid idea!
I already thought my approach to be lacking somewhere, although it was
too late last night to see where exactly. First off, the flag should,
of course be declared 'volatile'. If not, then there is no guarantee a
thread will see the
I've looked a little bit into this but I'm still in the process of
learning how the PropertyCache works.
I've done some statistics running a 100 page document (XSLT 1.0 spec in
FO) multiple times:
- New CacheEntry instances: 2410
- Cloned CacheEntry instances: 1010616
- Cloned CacheEntry
The attached patch should fix the memory leak Chris described (in one of
my runs the number of CacheEntry instances after a full GC went down
from 10575 (169KB, before the change) to 386 (6KB, after the change).
I've run various documents through the multi-threading testbed
application (in the
On Nov 14, 2007, at 11:34, Chris Bowditch wrote:
Andreas L Delmelle wrote:
Hi Andreas,
A splendid idea!
I already thought my approach to be lacking somewhere, although
it was too late last night to see where exactly. First off, the
flag should, of course be declared 'volatile'. If not,
On Nov 14, 2007, at 21:38, Jeremias Maerki wrote:
The attached patch should fix the memory leak Chris described (in
one of
my runs the number of CacheEntry instances after a full GC went down
from 10575 (169KB, before the change) to 386 (6KB, after the change).
I've run various documents
Andreas L Delmelle wrote:
On Nov 12, 2007, at 19:10, Andreas L Delmelle wrote:
Hi Chris
On Nov 12, 2007, at 18:29, Chris Bowditch wrote:
snip /
Thanks for the prompt reply! I've now committed the check for null
in the rehash method.
Good! Just checked the code more closely, and I
Andreas L Delmelle wrote:
Hi Andreas,
snip/
Just looked closer, and I may have found a slightly better way of
dealing with it.
Since the cause of the problem is CacheCleaners interfering with
rehash(), maybe the below patch is a better approach.
Once rehash() has been entered, and has
On Nov 13, 2007, at 18:02, Chris Bowditch wrote:
Hi Chris
snip/
Just looked closer, and I may have found a slightly better way of
dealing with it.
Since the cause of the problem is CacheCleaners interfering with
rehash(), maybe the below patch is a better approach.
Once rehash() has
Fellow FOP Devs,
periodically I run a test suite of documents against FOP Trunk to ensure
no new major issues have occurred since I last took a build of Trunk to
use in my application. Part of the test suite involves running a set of
a few documents several thousand times through FOP. After
Chris Bowditch wrote:
snip/
Does anyone know why CacheEntry.ref can be null in this context and why
this only happens after a few thousand documents have been run through?
Previous documents all have the same property values. Perhaps the GC has
collected the object referenced by ref?
A lot
On Nov 12, 2007, at 15:46, Chris Bowditch wrote:
Hi Chris
snip/
Does anyone know why CacheEntry.ref can be null in this context
and why this only happens after a few thousand documents have been
run through? Previous documents all have the same property values.
Perhaps the GC has
Andreas L Delmelle wrote:
snip/
A lot of the code that accesses the ref member variable has checks
for null and since it is a WeakReference I assume the cause of this
error is the Garbage Collector removing the reference. Adding a check
for null in the rehash method seems to avoid the
On Nov 12, 2007, at 18:29, Chris Bowditch wrote:
Andreas L Delmelle wrote:
snip/
A lot of the code that accesses the ref member variable has
checks for null and since it is a WeakReference I assume the
cause of this error is the Garbage Collector removing the
reference. Adding a
On Nov 12, 2007, at 19:10, Andreas L Delmelle wrote:
Hi Chris
On Nov 12, 2007, at 18:29, Chris Bowditch wrote:
snip /
Thanks for the prompt reply! I've now committed the check for null
in the rehash method.
Good! Just checked the code more closely, and I think your
suggestion is
30 matches
Mail list logo
