-----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 further): 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" serialization.
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 dividends.
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 -- Peter B. West <http://www.powerup.com.au/~pbwest/resume.html>
