Hi Clemens,
Clemens Eisserer wrote:
3.) http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6253009
Mentions a deadlock problem that can occur with a seperate lock for
the RenderQueue.
For my X11 pipeline it would be enough to ensure only one thread does
access xlib, it does not have to be always the queue-flush thread. So
if I would allow sync()/flushNow() on any thread, the problem would
not exist, right?
4.)
If the thread calling sync() sees theInstance as null, this means
that it could not have anything to sync
As far as I understand the JMM, it could be that thread1 already
called getInstance() (which creates and sets theInstance()), but
thread2 calls sync() - but sees null. Don't know wether a lost sync()
could be a problem at all.
It might be a problem in an unlikely scenario where an application
uses a thread to only call sync() from it and never calling
any getInstance().
5.)
Anyway, I would suggest that you look at optimizing
this later
Yes, that would be probably the best.
I was just a bit worried which design I should choose.
The JNI-overhead itself (35 cycles, Core2Duo) is so small, that I am
not sure wether the whole Buffered Rendering is a win at all.
I benchmarked the switch-statement which is used to decode the
command-stream and on my Core2Duo. Only calling the switch in a loop
already takes 20 cycles (which is quite reasonable keeping in mind the
generated table-jump puzzles the pipeline). Add the overhead of
stream-encoding, inter-thread communication and I guess it's also
somewhere between 30-50 cycles per j2d-primitive.
However if I could remove most of the locking, which at least on my
machine seems to add a lot of overhead, this would justify the
additional code.
With thread-private buffers, and all threads allowed to flush the
queue themself instead of relying on the queue-flush-thread to do it,
it should be possible.
You're welcome to implement the pipeline however you wish.
One of the main reasons behind STR was to improve the stability
of the OpenGL pipeline since OpenGL doesn't like to be accessed
from multiple threads - the JNI overhead reduction was a
welcome benefit. Same happen to be the case for the new
Direct3D pipeline.
If your pipeline doesn't have this restriction and you
apparently are satisfied with JNI performance, don't
use STR for your pipeline. After all, the current X11 pipeline
doesn't use it, and you can still use a few tricks from
it to reduce the JNI overhead (like doing all validation on
the java level).
Thanks,
Dmitri
