[OpenJDK 2D-Dev] Thread-Private RenderBuffers for RenderQueue?
linuxhippy at gmail.com
Mon Mar 24 17:57:26 UTC 2008
> 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,
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?
More information about the 2d-dev