[OpenJDK 2D-Dev] Thread-Private RenderBuffers for RenderQueue?

[Clemens Eisserer]

Hello,

>    Since most applications do render from one thread (either the
>    Event Queue like Swing apps, or some kind of dedicated rendering
>    thread like games), the lock is indeed very fast, given
>    biased locking and such.
>
>    I would suggest not trying to optimize things - especially tricky
>    ones which involve locking - until you have
>    identified with some kind of tool that there's a problem.

I did some benchmarking to find out the best design for my new
pipeline, and these are the results I got:

10mio solid 1x1 rect, VolatileImage, server-compiler, Core2Duo-2ghz,
Intel-945GM, Linux:

200ms no locking, no native call
650ms locking only
850ms native call, no locking
1350ms as currently implemented in X11Renderer

I did rendering only from a single thread (however not the EDT), in
this simple pipeline-overhead test the locking itself is almost as
expensive as the "real" work (=native call), and far more expensive
than an "empty" JNI call.
However this was on a dual-core machine, on my single-core amd64
machine locking has much less influence. As far as I know biased
locking is only implemented for monitors.
Xorg ran on my 2nd core, and kept it with locking only 40% busy,
without locking about 80%.

However I have to admit there are probably much more important things
to do than playing with things like that ;)


>    If it appears null during a sync() call, no harm is done (the
>    sync is just ignored - which is fine given that the render queue
>    hasn't been created yet, so there's nothing to sync), so this is
>    not a problem.
But what does happen if it has already been created, but the thread
calling sync() just does not see the updated "theInstance" value?
Could there be any problem when sync()-calls are left out?

lg Clemens