JNA Callback overhead - fyi
neilcsmith.net
Best wishes, Neil
--
Neil C Smith
Artist : Technologist : Adviser
http://neilcsmith.net
Andres Colubri
Do you see the garbage collection reduction also happening in gstreamer-java?
Thanks
Andres
--
You received this message because you are subscribed to the Google Groups "gstreamer-java" group.
To view this discussion on the web visit https://groups.google.com/d/msg/gstreamer-java/-/lTP3d_E_Cn4J.
To post to this group, send email to gstream...@googlegroups.com.
To unsubscribe from this group, send email to gstreamer-jav...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/gstreamer-java?hl=en.
Neil C Smith
Hi,
On Aug 11, 2011 8:23 PM, "Andres Colubri" <andres....@gmail.com> wrote:
>
> Hello Neil, this is great news! Thanks for the heads-up. I imagine that these improvements in JNA would eventually make their way into a future stable release.
>
I certainly hope so!
> Do you see the garbage collection reduction also happening in gstreamer-java?
>
This garbage collection result is with Gstreamer-java - it's about 8x less frequent. There is a small reduction in CPU usage with Gstreamer-java, but less noticeable than with JNAJack - not often you work with video at 500fps!
Best wishes, Neil
Farkas Levente
> As I've mentioned here before, I'm using GStreamer-Java as part of my
> Praxis software. Also part of Praxis is a JNA based binding to JACK
> (here if anyone's interested
> improving the performance of that library I noticed a major bottleneck
> in the callback code in JNA to do with thread detachment. In case
> you're not on the JNA list I wanted to being your attention to this
> thread -
> https://groups.google.com/d/topic/jna-users/bxd-yf2Al9g/discussion and
> the new JNA branch mentioned. I've been testing with my own hacked
> version of JNA that doesn't do thread detachment (not with this branch
> yet) and I can also see a small performance improvement with
> GStreamer-Java, as well as a massive reduction in garbage collection
> (almost an order of magnitude difference!)
can you tell me a little bit more about it?
since yesterday we recognize that there are a few remaining java object
in gstreamer-java when using callbacks which are never gc-d so may be
you can help us to solve it too!?
--
Levente "Si vis pacem para bellum!"
Neil C Smith
---------- Forwarded message ----------
From: Neil C Smith <ne...@neilcsmith.net>
Date: 13 August 2011 18:30
Subject: Re: JNA Callback overhead - fyi
To: Farkas Levente <lfa...@lfarkas.org>
On 13 August 2011 09:22, Farkas Levente <lfa...@lfarkas.org> wrote:
> On 08/11/2011 07:03 PM, neilcsmith.net wrote:
>> As I've mentioned here before, I'm using GStreamer-Java as part of my
>> Praxis software. Also part of Praxis is a JNA based binding to JACK
>> (here if anyone's interested
>> <http://code.google.com/p/java-audio-utils/>). While working on
>> improving the performance of that library I noticed a major bottleneck
>> in the callback code in JNA to do with thread detachment. In case
>> you're not on the JNA list I wanted to being your attention to this
>> thread -
>> https://groups.google.com/d/topic/jna-users/bxd-yf2Al9g/discussion and
>> the new JNA branch mentioned. I've been testing with my own hacked
>> version of JNA that doesn't do thread detachment (not with this branch
>> yet) and I can also see a small performance improvement with
>> GStreamer-Java, as well as a massive reduction in garbage collection
>> (almost an order of magnitude difference!)
>
> can you tell me a little bit more about it?
Basically, when a native thread (ie. GStreamer callback) needs to call
into the JVM, it has to attach itself - this creates a Java Thread
object to act as a proxy for it, and does various other things. The
way JNA does callbacks from a native thread, and to be fair the way it
seems to be advised in various places to do it, is to attach the
thread -> call the Java callback -> detach the thread, on every
callback! When you've got a long running regular callback from the
same thread (as in GStreamer-Java or JNAJack) you can get away with
just attaching once and keeping the proxy around until you're done
with it (at which point you ideally need to detach the thread or you
get a small memory leak).
Try looking at a GStreamer-Java application in VisualVM and notice the
huge number of thread objects that are being created, all of which
require overhead to setup and cause excessive GC. The modification
being discussed on the JNA mailing list will allow us to control
thread attachment/detachment manually through JNA, and thus remove
this performance penalty.
> since yesterday we recognize that there are a few remaining java object
> in gstreamer-java when using callbacks which are never gc-d so may be
> you can help us to solve it too!?
>
What objects? I have a suspicion, but you'd probably be better asking
on the JNA list. Over the last week or so I've learnt more about JNI
and JNA's internals than I ever intended to, but I still know very
little! :-)
Neil C Smith
On 11 August 2011 20:22, Andres Colubri <andres....@gmail.com> wrote:
> Hello Neil, this is great news! Thanks for the heads-up. I imagine that
> these improvements in JNA would eventually make their way into a future
> stable release.
>
Well, sometime later ... JNA 3.4.0 was released earlier this week, and
includes this most welcome improvement. The JavaDoc link is not
pointing to the right place right now, but will hopefully be fixed
soon. Look out for the new class CallbackThreadInitializer, along
with Native.detach(boolean).
My priority will be to add support for this to JNAJack (seen as that's
why it was requested and it has more to gain), but after that I'm
happy to help out with GStreamer-Java if needed, as Praxis will
benefit from that too. It shouldn't be much work, though you may want
to do what I'm planning with JNAJack and call using reflection so as
not to require 3.4.0+
It should also be possible to experiment with this in user code - eg.
call Native.detach(false) at the end of an RGBDataSink.Listener. If
all is working to plan you should see the thread count remain stable
in VisualVM, with less GC and (mildly) less CPU usage.
In "mildly related" news, a new Praxis LIVE early access release is
up, bringing the start of the OpenGL pipeline (though not for many ops
yet). Great fun for live-coded manipulation of GStreamer sources!
See here http://praxisintermedia.wordpress.com/
chrisb
Did you get a chance to port 3.4.0jna and the new callback
functionality to gstreamer-java ?
I would be keen to get my hands on this, I see there was a memory leak
found and fixed in the jna code after the last set of 3.4.0 libs, so
might be worth upgrading to trunk.
Also we should probably get gstreamer-java onto 3.4.0jna as I believe
there were quite a few fixes since 3.2.5.
Farqas what do you think ?
I see your comment about some objects not getting garbage collected,
do u think moving to this callback scheme will help?
Chris
On Dec 2, 11:27 am, Neil C Smith <n...@neilcsmith.net> wrote:
> Hi All,
>
> On 11 August 2011 20:22, Andres Colubri <andres.colu...@gmail.com> wrote:
>
> > Hello Neil, this is great news! Thanks for the heads-up. I imagine that
> > these improvements in JNA would eventually make their way into a future
> > stable release.
>
> Well, sometime later ... JNA 3.4.0 was released earlier this week, and
> includes this most welcome improvement. The JavaDoc link is not
> pointing to the right place right now, but will hopefully be fixed
> soon. Look out for the new class CallbackThreadInitializer, along
> with Native.detach(boolean).
>
> My priority will be to add support for this to JNAJack (seen as that's
> why it was requested and it has more to gain), but after that I'm
> happy to help out with GStreamer-Java if needed, as Praxis will
> benefit from that too. It shouldn't be much work, though you may want
> to do what I'm planning with JNAJack and call using reflection so as
> not to require 3.4.0+
>
> It should also be possible to experiment with this in user code - eg.
> call Native.detach(false) at the end of an RGBDataSink.Listener. If
> all is working to plan you should see the thread count remain stable
> in VisualVM, with less GC and (mildly) less CPU usage.
>
> In "mildly related" news, a new Praxis LIVE early access release is
> up, bringing the start of the OpenGL pipeline (though not for many ops
> yet). Great fun for live-coded manipulation of GStreamer sources!
> See herehttp://praxisintermedia.wordpress.com/
Neil C Smith
On 17 December 2011 09:44, chrisb <ch...@crazyfool.org> wrote:
> Did you get a chance to port 3.4.0jna and the new callback
> functionality to gstreamer-java ?
>
Not yet. I haven't even got around to getting the change into JNAJack
yet (and that was the project it was requested for!) I'm working flat
out on Praxis over the next few weeks, so won't have a chance to look
at GStreamer until after the New Year.
> I would be keen to get my hands on this, I see there was a memory leak
> found and fixed in the jna code after the last set of 3.4.0 libs, so
> might be worth upgrading to trunk.
>
If that's Jesse Glick's report on NativeMappedConverter, I'm not sure
that would be big issue in normal usage.
> Also we should probably get gstreamer-java onto 3.4.0jna as I believe
> there were quite a few fixes since 3.2.5.
>
> Farqas what do you think ?
>
> I see your comment about some objects not getting garbage collected,
> do u think moving to this callback scheme will help?
>
The callback code was causing excessive GC (of Thread and related
objects) but not a memory leak as far as I could see. This
enhancement will reduce CPU and GC overhead somewhat though.
If you want to give it a whirl, you could take the simple (but naive)
approach of just calling Native.detach(false) the first time into your
callback code. It's a good idea to do this as the last function in
your callback. This bypasses the need for the
CallbackThreadInitializer stuff, so you don't need any specific
reference to the underlying GStreamer-Java callback. Ideally, you
need to call Native.detach(true) the last time through your callback
as well.
Best wishes,
Neil
> --
> You received this message because you are subscribed to the Google Groups "gstreamer-java" group.
> To post to this group, send email to gstream...@googlegroups.com.
> To unsubscribe from this group, send email to gstreamer-jav...@googlegroups.com.
> For more options, visit this group at http://groups.google.com/group/gstreamer-java?hl=en.
>
--