Andreas L. Delmelle wrote:
-----Original Message-----
From: Peter B. West [mailto:[EMAIL PROTECTED]

<snip />

The borderline cases may be very much in the minority (and must be,
judging by the degree of usage that FOP gets now) but they must be taken
into account in the design of the solution.  If we go for the
low-hanging fruit and then discover that the ladder is too short we end
up back in the workshop.

I understand, but what I'm referring to is (taking your analogy a bit
You want an 'extensible' ladder which you can keep short for the low-hanging
fruit, and extend to reach the higher ones. If you get to a tiny tree with a
huge ladder, you're going to be cursing yourself anyway as your big ladder
will make the job more difficult, IYKWIM (--you might not even need that
ladder, but still you carried it all the way down there...).

The point that would concern me is an API that forces the most trivial and
common cases into a processing-model that is actually meant to accommodate
rather complicated structures. So you'd end up having an overhead in 95% of
the cases, overhead which strictly speaking is meant to occur in only 5% of
the possible situations.
If it results in (virtually) no overhead at all, this point of course
dissolves totally... the ladder is then extensible in just the right way.

There's a lot of subjective judgement in making such calls, which is why it's useful to have a number of different opinions kicking ideas around.

I wasn't thinking of the buffers.  The re-usability of the buffers is
only relevant to static-content and markers, so I don't see that as a
major issue, and would expect to keep the static-content buffers for a
page in memory for the life of the page-sequence.  Markers are a bit
more problematical, and may well benefit from some "transparent"

Sorry, I'm still a bit misguided, it seems. This part, I already got, but...

I was thinking more of the "historical" parts of the FO and Area trees.

... putting quotes around there is to beg the question, so, would that be
the parts that have already been processed in some way?

Yes. Candidates would be FOs and areas associated with pages containing forward references, and, in general such objects associated with the current page sequence, from the point of view of possible layout optimisation.

 At one stage I considered linking all nodes in the FO tree with
reference objects, but I was concerned about the extra layer of
reference objects and their impact on memory and performance.  However,
when we get parallel FO tree, Area tree and rendering working it may pay

I find the language of the java.lang.ref package confusing, but I think
that phantom references open the possibility of performing serialization
 "on demand", when the object is queued for GC.

Can you elaborate a bit on this? AFAICT, the actual referent of a phantom
reference is itself unreachable through the reference object (the ref's
get() method always returns null), so you could indeed test via isEnqueued()
whether or not the referent of a phantom reference is queued for GC, and
then...? A soft reference at least would allow to get() the object and do
something with it or make it do something with itself before actually
clearing the ref.

As I say, I find the language confusing, but it seemed to me that, as long as the object being GC'd contained enough information to determine its origins, when it found its way onto the reference queue for disposal the thread responsible could serialize it just before it was destroyed, and store the information required for its recovery in the appropriate place. The same may be achievable using the other reference types.

Whether the imprecations against finalizers apply also to phantom reference finalizers I don't know.

Peter B. West <>

Reply via email to