Re: More about the effects of the PropertyCache

[ad...@rswheeldon.abelalways.co.uk]

Andreas L Delmelle writes:
 > Been reading up a bit on concurrency and synchronization and the  
 > likes, and I'm in the meantime quite convinced that the strategy  
 > should indeed be altered to move away from static final Maps. Don't  
 > know if Richard is still listening in and has any opinions/ideas?

I'm listening again. Been very busy for the last few weeks - moving
etc. I've missed most of the recent conversations so if there is
anything important, relevant and not covered on the 41044 messages
please let me know.

Back to the concurrency, I'm not sure entirely why this is an major
issue. As I understand it the generation of a single fop document is
mostly linear - i.e. single threaded.

Assuming we're dealing with the case of multiple documents
simultaneously (e.g. in a webapp), does anyone have usable numbers
on the number of possible threads?

 > I've been playing with trying to make the cache thread-local

If in doubt, you could always make the caching multi-level.
L1 is the current global cache. L2 is a thread-local equivalent
of the same - all pointing to the same properties (if required)
but with different access keys. The L2 cache in this case need
have no contention at all,

Richard

Re: More about the effects of the PropertyCache

[Manuel Mall <mm...@arcus.com.au>]

On Friday 03 August 2007 07:01, Andreas L Delmelle wrote:
> On Aug 1, 2007, at 10:06, Manuel Mall wrote:
> > On Wednesday 01 August 2007 15:45,
> > admin@rswheeldon.abelalways.co.uk
> >
> > What am I missing?
>
> You are not missing anything, AFAICT except that:
> ... FOP still aims for 1.4 compliance
> ... java.util.concurrent and like classes have not been implemented
> under 1.4 yet...
>

Andreas, you didn't quite answer my question. Why do we need a shared 
property cache and therefore synchronisation, etc.? Why can't we have a 
simple cache per FOP rendering run?

>
> Cheers
>
> Andreas

Manuel

Re: More about the effects of the PropertyCache

[Andreas L Delmelle <a_...@pandora.be>]

On Aug 1, 2007, at 10:06, Manuel Mall wrote:

> On Wednesday 01 August 2007 15:45, admin@rswheeldon.abelalways.co.uk
>
> What am I missing?

You are not missing anything, AFAICT except that:
... FOP still aims for 1.4 compliance
... java.util.concurrent and like classes have not been implemented  
under 1.4 yet...


Cheers

Andreas

Re: More about the effects of the PropertyCache

[Andreas L Delmelle <a_...@pandora.be>]

On Aug 9, 2007, at 19:00, Andreas L Delmelle wrote:

> On Aug 8, 2007, at 08:30, Manuel Mall wrote:
>
>> <snip />
>> Not quite my point. When you put your private implementation of an  
>> int
>> HashMap forward there were concerns raised about this as hard to
>> maintain and not really required. Now we have a custom implementation
>> of a concurrent hash map. Same concerns apply IMO.
>
> Concerns as Simple and Stupid as the cache IMO.

Before anyone (Manuel or Vincent, who opposed the idea of the IntMap  
in the first place) feels offended, let me clarify:
Why did you think I posted a proposal first, this time?

I do understand the concerns, and I agreed for the IntMap, since  
ultimately it was only used for a very small portion of FOP. The  
PropertyCache on the other hand, is a relatively crucial component as  
it heavily used (indirectly by the PropertyParser, for instance). As  
such, IMO, the added maintenance here is peanuts compared to the  
speed and memory benefits --provided that there is a heavy,  
noticeable performance penalty in real-time, and not only in the  
simulations I did.

That said, I did not read a veto anywhere... :o)


Cheers

Andreas

Re: More about the effects of the PropertyCache

[Andreas L Delmelle <a_...@pandora.be>]

On Aug 8, 2007, at 08:30, Manuel Mall wrote:

> <snip />
> Not quite my point. When you put your private implementation of an int
> HashMap forward there were concerns raised about this as hard to
> maintain and not really required. Now we have a custom implementation
> of a concurrent hash map. Same concerns apply IMO.

Concerns as Simple and Stupid as the cache IMO.

Cheers

Andreas

Re: More about the effects of the PropertyCache

[Manuel Mall <mm...@arcus.com.au>]

On Wednesday 08 August 2007 04:02, Andreas L Delmelle wrote:
> On Aug 4, 2007, at 13:22, Vincent Hennebert wrote:
> > Manuel Mall a écrit :
> > <snip/>
> >
> >> I have been following this discussion with very little attempt to
> >> understand the intricate technical details of concurrent maps etc,
> >> but
> >> I am wondering why we don't apply the KISS principle here?
>
> Oh, but it is Simple and Stupid. :-)
> Much simpler and much more stupid than our layoutengine or hyphenator
> or property resolution code 

Not quite my point. When you put your private implementation of an int 
HashMap forward there were concerns raised about this as hard to 
maintain and not really required. Now we have a custom implementation 
of a concurrent hash map. Same concerns apply IMO.

<snip/>
>
> Cheers
>
> Andreas

Manuel

Re: More about the effects of the PropertyCache

[Andreas L Delmelle <a_...@pandora.be>]

On Aug 4, 2007, at 13:22, Vincent Hennebert wrote:

> Manuel Mall a écrit :
> <snip/>
>> I have been following this discussion with very little attempt to
>> understand the intricate technical details of concurrent maps etc,  
>> but
>> I am wondering why we don't apply the KISS principle here?

Oh, but it is Simple and Stupid. :-)
Much simpler and much more stupid than our layoutengine or hyphenator  
or property resolution code or...

The initial version I posted earlier was in fact so stupid it still  
contained a huge design flaw.
Lucky for me, nobody actually took a look at the code... Either that,  
or I should assume that a whole lot of people looked at it, but no  
one understood it. But that doesn't make it 'not simple'!

>> IIRC the original problem was that the FOP memory footprint for
>> rendering large documents was causing issues. One set of culprits  
>> that
>> were identified were the properties. Given that a FOP rendering  
>> run is
>> single threaded, i.e. there are no threads created within FOP, why
>> don't we start with a property cache per run?

We have already started (a couple of months ago)... with static final  
caches. An idea that seems to do the job nicely, although there are  
some reservations on the performance penalty because the cache needs  
to be synchronized in that case.

OTOH, Richard also raised the question, and to be honest, I don't  
have a clue for the moment:
What are realistic numbers to measure that penalty with?

I tried spawning 10 threads, and the penalty was already significant,  
but... This is supposing that all those 10 threads would need to  
access the /same/ cache at the exact /same/ instant.

If each thread spends less than 10% of the time parsing properties,  
the chances of that happening become very little.

>> No threading issues, no performance issues, and large gains in  
>> memory footprint reduction.

Indeed, but I think that implementing that would be much more  
difficult than the current solution. Much less adhering to the  
beloved KISS-principle than a Simple and Stupid home-made  
Hashtable... :-)

>> That will even benefit the memory footprint of concurrent FOP runs.
>> Admittedly not to the extend as globally shared cache would do,  
>> but it
>> would be much simpler and we can use the standard Java collection
>> classes to implement it.
>
> I’m afraid I must agree with Manuel here; although I’m not very  
> familiar
> with that whole area and I may well be also missing something.
>
> It seems to me that the main problem of FOP is that it isn’t able to
> render big documents, and that properties only play a part in that
> problem. It might be more useful to try and optimize the whole  
> rendering
> process, from which everyone will benefit, those running FOP on a  
> server
> as well as all others. That’s not the same kind of effort but it’s as
> much important IMHO.
>
> A cache per rendering run would do the thing, wouldn’t it? Coupled  
> with
> a flyweight factory for those properties with a small number of  
> possible
> values, which themselves could be shared among the different threads.

Yes, but see my comments above: to implement this, we would be  
introducing yet another set of classes, making the property  
resolution code even more complicated than it already is. It only / 
seems/ simpler...

> Also, maybe it’s worth keeping in mind that while that’s not currently
> the case, we want to eventually make the rendering process
> multi-threaded. Although the two issues might actually not interfere.

Well, if anything, the big PRO for a concurrent, thread-safe cache  
should precisely be the prospect of FOP multithreading *internally*.  
In that case, the current solution --possibly over time again backed  
by a standard 1.5 ConcurrentHashMap-- at least offers something which  
a rendering-run-local cache would lack.


Cheers

Andreas

Re: More about the effects of the PropertyCache

[Vincent Hennebert <vi...@anyware-tech.com>]

Hi,

Manuel Mall a écrit :
<snip/>
> I have been following this discussion with very little attempt to
> understand the intricate technical details of concurrent maps etc, but
> I am wondering why we don't apply the KISS principle here?
>
> IIRC the original problem was that the FOP memory footprint for
> rendering large documents was causing issues. One set of culprits that
> were identified were the properties. Given that a FOP rendering run is
> single threaded, i.e. there are no threads created within FOP, why
> don't we start with a property cache per run? No threading issues, no
> performance issues, and large gains in memory footprint reduction.
>
> That will even benefit the memory footprint of concurrent FOP runs.
> Admittedly not to the extend as globally shared cache would do, but it
> would be much simpler and we can use the standard Java collection
> classes to implement it.

I’m afraid I must agree with Manuel here; although I’m not very familiar
with that whole area and I may well be also missing something.

It seems to me that the main problem of FOP is that it isn’t able to
render big documents, and that properties only play a part in that
problem. It might be more useful to try and optimize the whole rendering
process, from which everyone will benefit, those running FOP on a server
as well as all others. That’s not the same kind of effort but it’s as
much important IMHO.

A cache per rendering run would do the thing, wouldn’t it? Coupled with
a flyweight factory for those properties with a small number of possible
values, which themselves could be shared among the different threads.

Also, maybe it’s worth keeping in mind that while that’s not currently
the case, we want to eventually make the rendering process
multi-threaded. Although the two issues might actually not interfere.

WDYT?
Vincent

Re: More about the effects of the PropertyCache

[Manuel Mall <mm...@arcus.com.au>]

On Wednesday 01 August 2007 15:45, admin@rswheeldon.abelalways.co.uk 
wrote:
> Andreas L Delmelle writes:
<snip/>
>  > I've been playing with trying to make the cache thread-local
>
> If in doubt, you could always make the caching multi-level.
> L1 is the current global cache. L2 is a thread-local equivalent
> of the same - all pointing to the same properties (if required)
> but with different access keys. The L2 cache in this case need
> have no contention at all,
>

I have been following this discussion with very little attempt to 
understand the intricate technical details of concurrent maps etc, but 
I am wondering why we don't apply the KISS principle here?

IIRC the original problem was that the FOP memory footprint for 
rendering large documents was causing issues. One set of culprits that 
were identified were the properties. Given that a FOP rendering run is 
single threaded, i.e. there are no threads created within FOP, why 
don't we start with a property cache per run? No threading issues, no 
performance issues, and large gains in memory footprint reduction.

That will even benefit the memory footprint of concurrent FOP runs.  
Admittedly not to the extend as globally shared cache would do, but it 
would be much simpler and we can use the standard Java collection 
classes to implement it.

What am I missing?

> Richard

Manuel