On 20.07.2007 06:56:21 Andreas L Delmelle wrote:
On Jul 19, 2007, at 00:36, Andreas L Delmelle wrote:
On Jul 18, 2007, at 23:18, Jeremias Maerki wrote:
snip /
- One of the easiest candidates for another flyweight is probably
CommonHyphenation (56K instances, 2.3MB in my example). The
Hi Jens
Good idea, IMO! That's the street performer protocol [1]. Let's hope
there will be enough motivation (and time) around for someone.
[1] http://en.wikipedia.org/wiki/Street_Performer_Protocol
I don't know of an instance inside the ASF where this has been tried,
but I know this has been
Hi,
I second that, a good idea for sure!
Regarding how this may be done within the ASF, that's probably a
question we can ask on [EMAIL PROTECTED] Maybe the ASF itself can serve as
the SPP platform?
I think it's worth making a poll on fop-user to see how many users would
be ready to participate
On 20.07.2007 10:06:55 Vincent Hennebert wrote:
Hi,
I second that, a good idea for sure!
Regarding how this may be done within the ASF, that's probably a
question we can ask on [EMAIL PROTECTED] Maybe the ASF itself can serve as
the SPP platform?
I'm 99.9% sure that it would not. There
Andreas L Delmelle wrote:
On Jul 19, 2007, at 18:15, Andreas L Delmelle wrote:
FWIW, I did a quick while(true){...} test with a modified version of
our ExampleFO2PDF. With basic documents, I can't seem to reproduce it.
The last cycle, I stopped at 1 renderings, but I'm pretty sure it
Andreas L Delmelle wrote:
On Jul 19, 2007, at 18:01, Chris Bowditch wrote:
Andreas L Delmelle wrote:
If there is anything special about that file, you could always post
it, but I'll try to see if I can reproduce with a simple FO without
special features. If I don't succeed, I might ask
Andreas L. Delmelle wrote:
That's one detail I was still unsure about. Only if the other factors
remain identical, the algorithm would prefer a break at penalty 50
over one at penalty 100... but if the value of the penalty is only of
marginal influence as you suggest, then this would indeed
On 20.07.2007 10:45:44 Chris Bowditch wrote:
Andreas L Delmelle wrote:
On Jul 19, 2007, at 18:15, Andreas L Delmelle wrote:
FWIW, I did a quick while(true){...} test with a modified version of
our ExampleFO2PDF. With basic documents, I can't seem to reproduce it.
The last
Well done, Andreas!
snip/
In the process, some oddities that caught my eye in the javadocs were
corrected as well. On the other hand, I do not completely rule out that
new oddities have been introduced (the diff being +16000 lines), so keep
your eyes open for those...
IMO it's perfectly fine
FWIW, I completely agree with the realization that integer keep values
cannot be directly mapped to penalty values and that the breaking algorithm
may have to be called multiple times with different penalty values to
get the right results.
more inline...
On 20.07.2007 10:52:59 Luca Furini wrote:
Chris Bowditch wrote:
Andreas L Delmelle wrote:
On Jul 19, 2007, at 18:01, Chris Bowditch wrote:
Andreas L Delmelle wrote:
If there is anything special about that file, you could always
post it, but I'll try to see if I can reproduce with a simple FO
without special features. If I
On Jul 20, 2007, at 08:02, Manuel Mall wrote:
On Jul 20, 2007, at 05:47, Manuel Mall wrote:
snip/
As to how the TextLM should then further handle it, I hadn't really
looked deeper into so far, but it seems like you have... 8-)
Andreas, how about this as a way forward: You implement the
On Jul 20, 2007, at 11:19, Jeremias Maerki wrote:
The initial profile shows that instances of WeakHashMap$entry and
org.apache.fop.fo.properties.FixedLength continually grow with the
life
of JVM.
Interesting coincidence:
That's exactly what Andreas already wrote about in the other thread
On 20.07.2007 11:52:15 Andreas L Delmelle wrote:
On Jul 20, 2007, at 11:19, Jeremias Maerki wrote:
The initial profile shows that instances of WeakHashMap$entry and
org.apache.fop.fo.properties.FixedLength continually grow with the
life
of JVM.
Interesting coincidence:
That's
Jeremias Maerki wrote:
On 20.07.2007 11:52:15 Andreas L Delmelle wrote:
snip/
In addition to that there was a bug in FixedLength.equals() that made
the caching effect-less:
http://svn.apache.org/viewvc?view=revrev=557934
That was the most likely cause. The equals() method returning
On 20.07.2007 12:51:33 Chris Bowditch wrote:
Jeremias Maerki wrote:
On 20.07.2007 11:52:15 Andreas L Delmelle wrote:
snip/
In addition to that there was a bug in FixedLength.equals() that made
the caching effect-less:
http://svn.apache.org/viewvc?view=revrev=557934
That was the
I'm 99.9% sure that it would not. There were discussions about that in
the past and the members' opinion was to keep such things separate from
the ASF. The ASF would never pay anyone to make an improvement on one of
the projects since it's a NPO and there are certain rules around that
status.
Sorry, but I don't agree. Anyone else?
On 20.07.2007 14:01:52 Andreas L Delmelle wrote:
On Jul 20, 2007, at 11:58, Jeremias Maerki wrote:
Read again: Implementation note: The value objects in a
WeakHashMap are
held by ordinary strong references. That means that all the object in
Another argument: Why did Chris have an OutOfMemoryError in the first
place that the fix for FixedLengthProperty solved? The OutOfMemoryError
doesn't happen anymore because not so many objects are created to
actually be filling the memory. If the objects in the cache had been
releasable, they
Fixed my patch and attached it.
Adrian.
Chris Bowditch wrote:
Jeremias Maerki wrote:
On 20.07.2007 12:51:33 Chris Bowditch wrote:
Jeremias Maerki wrote:
On 20.07.2007 11:52:15 Andreas L Delmelle wrote:
snip/
In addition to that there was a bug in FixedLength.equals() that made
the
Want to find a memory leak? SAP's memory analyzer is great again to find
out all paths to GC roots:
Class Name
|Shallow Heap |Retained Heap
Adrian,
you forgot to account for the case where the GC removes the instance in
the worst possible moment and WeakReference.get() returns null.
On 20.07.2007 16:33:34 Adrian Cumiskey wrote:
Index: src/java/org/apache/fop/fo/properties/PropertyCache.java
Attached revised fix.
Jeremias Maerki wrote:
Adrian,
you forgot to account for the case where the GC removes the instance in
the worst possible moment and WeakReference.get() returns null.
On 20.07.2007 16:33:34 Adrian Cumiskey wrote:
Index:
Perhaps I'm being a bit dim, but ...
Why store the Property as a key and a value both? Just store as the
value. You can still get a list of all the cached Property objects by
calling keySet(). The entries in the Set returned may be WeakReference
objects, but that's easily dealt with.
Just
On Jul 20, 2007, at 17:15, Mark C. Allman wrote:
Hi Mark
Perhaps I'm being a bit dim, but ...
Why store the Property as a key and a value both? Just store as
the value. You can still get a list of all the cached Property
objects by calling keySet(). The entries in the Set returned may
On Jul 20, 2007, at 16:51, Jeremias Maerki wrote:
Want to find a memory leak? SAP's memory analyzer is great again to
find
out all paths to GC roots:
snip /
As a simplification here, let's assume cache (PropertyCache in
static
variable) is our GC root. Hard references are to propCache,
On Jul 20, 2007, at 09:19, Jeremias Maerki wrote:
snip /
This means we currently end up in the strange situation where
different/separate CommonHyphenation instances are generated from
identical sets of base Property instances.
Raises the question for me if for properties without dynamic
On Jul 18, 2007, at 22:17, Jeremias Maerki wrote:
FWIW: going over those initial figures again, and
Class
Name |
Objects |Shallow Heap |Retained Heap |Perm
--
28 matches
Mail list logo
