copyReference() should avoid making JNI calls

[GoogleCodeExporter]

In Xuggler 3.0 and before, copyReference() relied on the underlying native
code to increment and decrement object reference counts.  While this is
correct, it does mean a copyReference() had to go across the JNI boundary
which results in copyReference() being slower than optimal.

In multi-threaded programs that use copyReference() to maintain object
lifetimes across threads, this can become burdensome.  So instead we should
maintain a Java proxy-ref count that shares the native ref-count, and only
cross the JNI boundary for acquire on initial object constructions, and
only cross the JNI boundary for release on the last java object destruction.

Original issue reported on code.google.com by art.cla...@gmail.com on 23 Jun 2009 at 6:31

[GoogleCodeExporter]

Implemented in r712

The net result of this is that copyReference() performance improves by about 
50%. 
For users who are wondering if you're not using copyReference() there is no
performance penalty for this, and if you are using it in single-threaded 
programs you
probably won't see a performance gain.

But if you're running in multi-threaded programs that do a lot of 
copyReference()
calls to pass objects across boundaries, the savings can start to be 
significant.  In
one of our projects (a large-scale conferencing solution) this change resulted 
in a
5% increase in throughput.

Original comment by art.cla...@gmail.com on 23 Jun 2009 at 6:34

• Changed state: Completed