We're going to change the Xuggler object allocation scheme that ensures
automatic collection:
In Xuggler 3.1 the basic scheme is:
- On .make()
- Create native Object
- Create Java proxy Object
- Acquire global lock
- Add Reference to a global Set so that when the underlying Xuggler
object is collected the Reference gets put on a Reference Queue
- On .delete()
- Release native memory
- Acquire global lock
- Remove reference from set
Turns out in performance testing when allocating lots of Xuggler objects
(2-3mm) the overhead of those locks really really matter. So in Xuggler
3.2 we're going to move to a collect-and-sweep mechanism instead:
- On .make()
- Create native Object
- Create Java proxy Object
- Acquire global lock
- Increment index in Reference array. If the index goes above
our collection-threshold, sweep and collect.
- Add Reference to a global Set so that when the underlying Xuggler
object is collected the Reference gets put on a Reference Queue
- On .delete()
- Release native memory
This will eliminate locking entirely on the delete operation, at the
expense of collections during some adds. Under typical usage scenarios
(where multiple threads are allocating and nulling objects), changing to
this scheme appears to speed up object allocation and deallocation by about
30%.
Original issue reported on code.google.com by art.cla...@gmail.com on 20 Jul 2009 at 9:54
Original issue reported on code.google.com by
art.cla...@gmail.com
on 20 Jul 2009 at 9:54